DDD应用服务中的CRUD？

Question

我是DDD的新手，但我正在尝试将DDD概念纳入我当前的项目中。

对于我域中的许多实体，客户端需要独立于任何特定工作流执行所有标准CRUD操作。我发现自己有许多应用程序级服务，其名称类似于UserService或LocationService，它们只是作为各个存储库的外观。

这些应用程序服务是否作为存储库外观＆＃34;正确＆＃34;应用服务模式的应用？或者CRUD专用方法是否应该停止应用程序服务？如果是这样，接口层是否应该有一个存储库外观？

Answer 1

这当然取决于应用程序，也可能是一种品味问题，其中一些人选择更直接的方法并将存储库直接暴露给客户端。这种方法的一个好处是简单。您没有遍历图层来跟踪代码的执行。另一方面，应用程序服务的角色是域层的Facade或API。

换句话说，应用程序服务封装了域层并协调域逻辑的执行。通过此标记，存储库也可以由应用程序服务封装。在这种情况下的好处可以是一致性，即域层的所有客户端通过应用程序服务与其交互，无论它们是发出命令还是检索数据。

最佳解决方案取决于您的应用程序。如果所有必需的功能都是CRUD或主要是CRUD，则不需要应用程序服务（或完整的DDD），因为在这种情况下，所有服务都委托给存储库，因此增加了不必要的复杂性。但是，应用程序服务也可以是一个方便的联结，用于管理存储库不应该处理的事务和工作单元。

另一种方法是将此职责委托给托管环境的基础结构，例如ASP.NET MVC应用程序中的操作筛选器。

---

Answer 2

如果您的域名需要CRUD样式的用例，那么它们是正确的。

在我看来，直接公开存储库是错误的，因为应用程序服务的职责不仅包括＆＃34;只是＆＃34;功能用例;这是事务控制，安全性和基本输入验证。

Answer 3

您的应用程序服务中的方法应具有代表您的用例的名称。在DDD中经常说你应该避免使用CRUD，但根据我的经验，产品所有者/领域专家经常谈论“创建”或“添加”实体，以及“更新”，“编辑”或“修改”和实体。如果这些是您负责实施的用例，那么它们肯定会在您的应用程序层中。

如果产品所有者正在谈论反映CRUD，那么它应该在那里，但如果他们用不反映CRUD的术语说话，那么你应该避免它。