我的同事告诉我——我们没有业务逻辑，我们只有像 GetById、GetBySearchTerm、GetByParentID 这样的 CRUD ......所以我开始怀疑这些词。
在阅读了 DDD 之后，这些方法是 CRUD，它们具有基于某些特定代码（通常是 SQL）获取数据（也存储、更新、删除......）的机制。
如果业务分析师对我说：“我们需要显示有关特定客户的数据”。在我看来，这是一个业务流程（GetById），GetById 应该放在应用程序的业务逻辑部分中，并与存储库联系以获取数据。具有 CRUD 方法的存储库负责根据某些标准持久化数据。
我知道这个问题可能会引发关于拥有原子方法（GetById、GetBySearchTerm、GetByParentiId ...）的存储库的争论，但我的问题很简单——这些方法是 CRUD 还是业务逻辑方法。
简短的回答是，除了作为事物写入/事务方面一部分的域操作之外，您不应该出于任何原因查询域模型。这方面对在您的域发出的命令更感兴趣，以便执行/执行操作。
与显示数据相关的任何事情都应该来自尽可能简单的查询/读取模型。
如果您发现您的查询需要域交互，您可能有一个场景，您可能需要告诉您的域做某事，一旦完成，您可以通过查询端请求数据。
这些方法根本不可能是商业方法。作为 CQRS 从业者，我建议您在命令和查询方面使用不同的模型。可能是您创建了一个不同的有界上下文来服务于整个阅读（查询）过程（您可以在此处创建贫血/DTO）和另一个服务于纯业务逻辑目的的域模型。
您可以查看我的博客以了解命令和查询的分离。
https://aspxsushil.wordpress.com/2015/10/18/command-and-query-object-pattern/
并非每个应用程序都是 DDD 应用程序。有些应用程序只是简单的 CRUD
业务逻辑将是您验证输入的应用程序的一部分（例如通过 id 获取，并且 id 是 1 到 99999 之间的数字）。然后将其传递到存储库以进行实际查询。
但是，如果您的应用程序真的是一个杂乱无章的应用程序，那么尝试应用 DDD 对您没有帮助。