我是 DDD 新手，但我正在尝试将 DDD 概念整合到我当前的项目中。
对于我域中的许多实体，客户需要独立于任何特定工作流程执行所有标准 CRUD 操作。我发现自己拥有许多应用程序级服务，它们的名称如 UserService 或 LocationService ，它们只不过是各自存储库的外观。
这些作为存储库外观的应用程序服务是应用程序服务模式的“正确”应用程序吗？还是应该只使用 CRUD 的方法远离应用程序服务？如果是这样，接口层是否应该有一个存储库外观？
【问题讨论】：
标签： design-patterns architecture repository domain-driven-design
这当然取决于应用程序，也可能是个人喜好问题，有些人选择更直接的方法并将存储库直接暴露给客户。这种方法的一个好处是简单。您没有遍历层来跟踪代码的执行。另一方面，应用程序服务的角色是领域层的外观或 API。
换句话说，应用服务封装了领域层并协调领域逻辑的执行。通过这个标记，存储库也可以被应用程序服务封装。这种情况下的好处可能是一致性，因为域层的所有客户端都通过应用程序服务与其交互，无论它们是发出命令还是检索数据。
最佳解决方案取决于您的应用。如果所有必需的功能都是 CRUD 或主要是 CRUD，则不需要应用程序服务（或完全成熟的 DDD），因为在这种情况下，所有服务都委托给存储库，因此增加了不必要的复杂性。但是，应用程序服务也可以是管理事务和工作单元的便捷连接点，存储库不应该处理这些事务和工作单元。
另一种方法是将此责任委托给托管环境的基础架构，例如 ASP.NET MVC 应用程序中的操作过滤器。
【讨论】：
如果您的域需要 CRUD 风格的用例，那么它们是正确的。
在我看来，直接公开存储库是错误的，因为应用程序服务的职责不仅仅包括“仅”功能用例；即事务控制、安全性和基本输入验证。
【讨论】：
您的应用程序服务中的方法应该具有代表您的用例的名称。在 DDD 中经常说您应该避免 CRUD，但根据我的经验，产品所有者/领域专家经常谈论“创建”或“添加”实体，以及“更新”、“编辑”或“修改”和实体。如果这些是您负责实施的用例，那么它们肯定会在您的应用程序层中。
如果产品所有者在谈论反映 CRUD 的术语，那么它应该在那里，但如果他们在谈论不反映 CRUD 的术语，那么你应该避免它。
【讨论】：