我是 DDD 的新手，但我正在尝试将 DDD 概念融入我当前的项目中。
对于我域中的许多实体，客户端需要独立于任何特定工作流执行所有标准 CRUD 操作。我发现自己拥有许多应用程序级服务，它们的名称如 UserService 或 LocationService ，它们只不过是各自存储库的外观。
这些作为存储库外观的应用程序服务是否是应用程序服务模式的“正确”应用程序？还是应该只使用 CRUD 的方法远离应用程序服务？如果是这样，接口(interface)层是否应该有一个存储库外观？
最佳答案
这当然取决于应用程序，也可能是个人喜好问题，有些人选择更直接的方法并将存储库直接暴露给客户。这种方法的一个好处是简单。您没有遍历层来跟踪代码的执行。另一方面，应用程序服务的角色是领域层的外观或 API。
换句话说，应用服务封装了领域层并编排了领域逻辑的执行。通过这个标记，存储库也可以被应用程序服务封装。这种情况下的好处可能是一致性，因为域层的所有客户端都通过应用程序服务与其交互，无论它们是发出命令还是检索数据。
最佳解决方案取决于您的应用。如果所有必需的功能都是 CRUD 或主要是 CRUD，则不需要应用程序服务(或完全成熟的 DDD)，因为在这种情况下，所有服务都委托(delegate)给存储库，因此增加了不必要的复杂性。但是，应用程序服务也可以是管理事务和工作单元的便捷连接点，存储库不应该处理这些。
另一种方法是将此责任委托(delegate)给宿主环境的基础结构，例如 ASP.NET MVC 应用程序中的操作筛选器。
关于design-patterns - DDD 应用服务中的 CRUD？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/10324988/