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