我正在开发一个基于域驱动设计的项目。
在这个项目中，我们有5层：
我对如何将我的业务逻辑放在基础架构，域和服务层之间感到困惑。有时我将业务逻辑条件放在iqueryable Linq中的存储库中;有时我将所有对象加载到内存并将它们放入服务中;有时我把它们放在一个物体的方法中。我不知道哪种方式是正确的。哪个层应该负责这个业务逻辑？
我需要一些具体的理由来说服开发人员团队，代码中的业务逻辑更好，因为它更易于维护。我以前在数据库中有很多业务逻辑，因为我认为这是单点访问。
答案 0 :(得分：1)
存储过程对于加速某些数据库操作很有用。 存储过程是邪恶的，因为：
说...存储库的实现是基础设施，而基础设施并不了解域和业务逻辑。 毕竟我在这个问题上看不到DDD，也许你应该加深实体，价值对象和聚合根等概念，以及存储库和域模型。
我们现在唯一可以确认的是：作为域逻辑的业务逻辑属于域模型/域层。域逻辑是除了用例之外始终以相同方式起作用的规则（例如：如果订单比100美元更贵，那么货件是免费的）。 如果您的规则取决于用例（例如：如果用户使用appmobile浏览我的电子商务而不是......），这就是应用程序逻辑。
答案 1 :(得分：0)
DDD也遵循＆＃34;关注点＆＃34;规则所以围绕域的业务停留在域层中，如果域之外的东西依赖于那么我们将它们放在更高层，如表示层中的模型视图。
答案 2 :(得分：0)
我知道这很老了，但是我有一些在较旧的项目上工作的经验，这些项目的数据库包含所有逻辑，并且各种系统都使用了该逻辑。更新这些系统中的任何一个都成为噩梦，要对其中任何一个进行更改都会破坏其他地方的内容。
DDD旨在解决这些确切的情况。
想想它，因为您有一个专注于控制其域的应用程序，定义域通常很困难，但是可以说您可以定义一个具有3个域的传统系统。
Commerce Domain控制如何接受订单。
Logistics Domain控制如何下达订单。
有关如何付款的结算域。
理想情况下，这些域中的每个域都可以表示为分层应用程序，但是一个“订单”的整个端到端故事涉及所有3个应用程序。每个域都控制着自己的业务，并负责尽其所能尽其所能。
Billing Domain可以像将订单数据附加到csv文件的Web api一样简单，会计人员每月都要打开一次，然后手工输入发票。或者，它可能会发展成为一个庞大的，复杂的快速簿集成兽，它们会自动从已保存的帐户中提取资金。 Commerce and Logistics域不必关心计费域将数据保存在何处或如何获得付款。他们只是负责通知何时销售商品和何时发货的计费域。
Commerce域同样不必在乎运输成本的计算方式，它只需要询问Logistics领域。 Commerce不应扎根于Logistics所需的数据库中，因为如果Logistics要枢轴化并使用Google Maps确定运输成本，那么我们也需要更新Commerce。
一旦您了解了“每个域都控制着它的数据，如果您需要那个域数据，就询问那个域”的概念。接下来的几分会排在一行。
每个域都将有一个或两个表示层，这可以是网站，api，移动/桌面应用程序或上述的组合。每个域将在域/应用程序层中具有业务逻辑。每个域都将受到数据库和api等基础架构的支持。
在上面的示例中，我们可以有一个Commerce Domain。它的表示层将网站呈现给用户，它的域层由OrderPage和命令/查询的界面组成。它的基础结构层具有处理这些命令和查询的逻辑，其中大多数可能进入私有数据库，但是我们也有一些对后勤和计费域的api调用。
我们的计费域在其表示层中有2个项目。一个是用于处理来自Commerce和Logistics域的请求的API，另一个是我们编写的用于会计的桌面应用程序。他们都与同一个域对象/接口通信，因此，如果会计需要登录并手动修改订单，则可以像在网站上一样轻松地进行操作。域中的接口由基础结构实现，该基础结构可以是quickbooks api，也可以将数据转发到新书中，直到完成大迁移为止。商业和物流中的任何代码都不必关心新鲜书/快速书，如果需要，我们可以同时使用两者。
我们的Logicstics域在其表示层中同样有两个项目。一个控制台应用程序，它每天早上执行一次计划任务，以分批处理订单和api。同样处理数据。
好吧，时间太长了，我将总结一下。无论如何，没人会在4岁的帖子上读到这个答案。