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