>聚合和实体是实现域逻辑的主要对象。他们有国家和身份。在这种情况下，我将域逻辑看作是突破该状态的所有命令的集合。那有意义吗？为什么域逻辑仅与状态相关？模拟没有标识或没有状态的域对象是否合法？为什么域对象不能实现为事务脚本？示例：考虑一个对象，建议您为约会网站的合作伙伴。那个对象没有真正的状态，但是它有很多的域逻辑？将其放入服务层意味着域模型不能覆盖所有的逻辑。
>访问其他域对象。聚合可以访问存储库吗？示例：当(有状态)域对象需要访问系统的所有“用户”以执行其工作时，它将需要通过存储库访问它们。因此，ORM在加载对象时需要注入存储库(这可能在技术上更具挑战性)。如果对象无法访问存储库，那么在此示例中将域逻辑放在哪里？在服务层？服务层是不是没有逻辑？
>集体和实体不应该与外界交谈，他们只关心自己有限的背景。我们不应该将外部依赖项(如IPaymentGateway或IEmailService)注入域对象，这将导致域处理来自外部的异常。解决方案：基于事件的方法。那么你怎么发送事件呢？每次实例化域对象时，仍然需要注入正确的“监听器”。 ORM是关于恢复“数据”，但不是主要用于注入依赖关系。我们需要DI-ORM组合吗？
>域对象和DTO。当查询聚合根状态时，它会返回其状态(DTO)或域对象本身的投影吗？在我看到的大多数模型中，客户端可以完全访问域数据模型，引入与域的实际结构的深度耦合。我认为聚合后面的“对象图”是它自己的商业。那是封装，对吧？所以对我来说，一个聚合的根应该只返回DTO。 DTO通常在服务层定义，但我的方法是在域本身进行建模。服务层可能还会增加另一个抽象级别，但这是一个不同的选择。这是一个很好的建议吗？
>存储库处理聚合根级别的所有CRUD操作。其他查询怎么办？查询返回DTO而不是域对象。为了工作，代理人必须意识到引入耦合的域的数据结构。我的建议与以前类似：使用事件填充视图。因此，内部结构不公开，只有事件携带必要的数据来建立观点。
>工作单位系统边界的控制器将实例化命令并将其传递给服务层，服务层依次加载适当的聚合并转发命令。控制器可能会使用多个命令并将其传递给多个服务。这全部由工作单位控制。这意味着，存储库，实体和服务都参与同一个事务。你同意吗？
>商业逻辑不是域逻辑。从商业角度来看，用例的实现可能涉及许多步骤：注册客户，发送电子邮件，创建存储帐户等。此整个流程可能不可能适合域聚合根。域对象需要访问所有类型的基础设施。解决方案：工作流或sagas(或事务脚本)。这是一个很好的建议吗？

谢谢