>聚合和实体是实现域逻辑的主要对象。他们有国家和身份。在这种情况下，我将域逻辑看作是突破该状态的所有命令的集合。那有意义吗？为什么域逻辑仅与状态相关？模拟没有标识或没有状态的域对象是否合法？为什么域对象不能实现为事务脚本？示例：考虑一个对象，建议您为约会网站的合作伙伴。那个对象没有真正的状态，但是它有很多的域逻辑？将其放入服务层意味着域模型不能覆盖所有的逻辑。
>访问其他域对象。聚合可以访问存储库吗？示例：当(有状态)域对象需要访问系统的所有“用户”以执行其工作时，它将需要通过存储库访问它们。因此，ORM在加载对象时需要注入存储库(这可能在技术上更具挑战性)。如果对象无法访问存储库，那么在此示例中将域逻辑放在哪里？在服务层？服务层是不是没有逻辑？
>集体和实体不应该与外界交谈，他们只关心自己有限的背景。我们不应该将外部依赖项(如IPaymentGateway或IEmailService)注入域对象，这将导致域处理来自外部的异常。解决方案：基于事件的方法。那么你怎么发送事件呢？每次实例化域对象时，仍然需要注入正确的“监听器”。 ORM是关于恢复“数据”，但不是主要用于注入依赖关系。我们需要DI-ORM组合吗？
>域对象和DTO。当查询聚合根状态时，它会返回其状态(DTO)或域对象本身的投影吗？在我看到的大多数模型中，客户端可以完全访问域数据模型，引入与域的实际结构的深度耦合。我认为聚合后面的“对象图”是它自己的商业。那是封装，对吧？所以对我来说，一个聚合的根应该只返回DTO。 DTO通常在服务层定义，但我的方法是在域本身进行建模。服务层可能还会增加另一个抽象级别，但这是一个不同的选择。这是一个很好的建议吗？
>存储库处理聚合根级别的所有CRUD操作。其他查询怎么办？查询返回DTO而不是域对象。为了工作，代理人必须意识到引入耦合的域的数据结构。我的建议与以前类似：使用事件填充视图。因此，内部结构不公开，只有事件携带必要的数据来建立观点。
>工作单位系统边界的控制器将实例化命令并将其传递给服务层，服务层依次加载适当的聚合并转发命令。控制器可能会使用多个命令并将其传递给多个服务。这全部由工作单位控制。这意味着，存储库，实体和服务都参与同一个事务。你同意吗？
>商业逻辑不是域逻辑。从商业角度来看，用例的实现可能涉及许多步骤：注册客户，发送电子邮件，创建存储帐户等。此整个流程可能不可能适合域聚合根。域对象需要访问所有类型的基础设施。解决方案：工作流或sagas(或事务脚本)。这是一个很好的建议吗？
谢谢
>你的例子“考虑一个建议你做一个约会网站的合作伙伴的对象”，属于域服务(而不是基础设施服务)。看这篇文章 – http://lostechies.com/jimmybogard/2008/08/21/services-in-domain-driven-design/>聚合不直接访问存储库，但它们可以创建一个将多个域对象的操作组合成一个单元的工作单元。>不知道这个。这本来应该是一个问题。>这是有争议的，从理论上说，域实体不会在总根以外直接可用，但并不总是实用的。我根据具体情况考虑这一决定。>我不知道你的意思是什么是“查询”。如果对您域中所有可能的“阅读”情景进行建模似乎不实用或提供足够的性能，则表明CQRS解决方案可能是最好的。>是的，我同意。 UOW是您可以在各种图层中使用的工具箱中的工具。>这个说法根本错了“业务逻辑不是域逻辑”。域是表示业务逻辑，因此是使用普遍存在的语言的一个原因。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。