我的同事告诉我 - 我们没有业务逻辑，我们只有像GetById，GetBySearchTerm，GetByParentID ....的CRUD，所以我开始想知道关于这些话。是GetById，GetByX CRUD或业务逻辑方法或两者都
在阅读DDD之后，这些方法是CRUD，它们具有基于某些特定代码（通常为SQL）提取数据（也存储，更新，删除...）的机制。
如果业务分析师对我说：“我们需要显示关于特定客户的数据”。 在我看来，这是一个业务流程（GetById），GetById应该放在应用程序的业务逻辑部分中，它会联系存储库来获取数据。使用CRUD方法的存储库负责根据一些标准保存数据。我知道这个问题可能导致辩论存储与原子方法（GetById，GetBySearchTerm，GetByParentiId ...），但我的问题只是简单 - 这些方法是CRUD或业务逻辑方法。
简短的回答是，你不应该查询您的域模型比是写的东西/事务侧的一部分域操作之外的任何原因。这方面的东西更感兴趣的是在你的域名发出的命令，以便做/执行操作。
与显示数据进行任何应该来自这样的简单查询/读取模型的可能。
如果你发现你的查询需要域交互，你可能有一个场景，你可能需要告诉你的域做些事情，一旦完成，你可以通过查询端请求数据。
并非每个应用程序都是DDD应用程序。一些应用程序只是简单的CRUD
业务逻辑将是您验证输入的应用程序的一部分（如get by id和id是介于1和99999之间的数字）。然后将其传递给实际查询的存储库。
但是，如果您的应用程序确实是一个粗糙的应用程序，然后尝试应用DDD不会帮助你。
这些方法根本不可能是商业方法。作为一名CQRS从业者，我建议你为命令和查询一方提供不同的模型。可能是你创建了一个不同的有界的上下文，它服务于整个阅读（查询）过程（你可以在这里创建anemic/DTOs）和另一个服务于纯业务逻辑目的的域模型。
你可以看看我的博客命令和查询分离。
https://aspxsushil.wordpress.com/2015/10/18/command-and-query-object-pattern/
当应用程序查询数据时，它也是事务性过程。我想，我并没有激怒你。你可以详细说明，还是简化你的答案。 – user2457382
通常，当您查询数据时，它不是事务性的。使用交易进行选择没有太大意义。无论如何，我的意思是事物的命令/写入方面的事务（OLTP），而不是读取数据（与OLAP更密切相关）。 –