domain-driven-design - 领域驱动设计与命令模式——相互排斥？

Question

tl;博士:
我喜欢命令模式的小型集中类，例如 SetProjectAsActiveCommand但我也是DDD的让模型负责自己的核心业务功能的方法，比如调用Project::setAsActive() . 这两个想法可以一起工作，还是相互排斥的架构？
/tl;博士

过去几个月我一直在做一个项目，我们一直在使用命令模式，它有像 ProposeNewProjectCommand 这样的类。 , SetProjectAsActiveCommand , 和 AddCommentToProjectCommand ，所有这些都由命令总线处理。这些类(class)往往规模较小且专注，只做一件事。

最近我一直在阅读有关领域驱动设计 (DDD) 的文章，我认为这种方法更多地依赖于模型自己工作，因此上面的命令可能会替换为 Organisation::proposeNewProject() , Project::setAsActive() , 和 Project::addComment() .

在模型上使用这些方法意味着它们可以充当“聚合根”(例如，在上面的示例中，Project 负责创建自己的评论)。

虽然我真的很喜欢让我的实体对其核心业务功能承担更多责任的想法，但我也担心我的模型可能会变得非常非常大，其中有很多与应用程序可以做的各种事情相关的方法.

有没有办法让命令模式的小型、集中的类同时仍然让模型成为负责其关键业务功能的一等公民，就像在 DDD 中一样？或者解决潜在的大型模型问题的方法？

或者，或者，我应该只选择一种模式并专门使用它吗？

提前感谢您提供的任何见解，
哈里森

PS。我从未真正开发过使用 DDD 的应用程序，所以如果这是一个非常幼稚的问题，我深表歉意。

Answer 1

是什么让 DDD 成为您开始更多地考虑语言，您试图在代码中找到一个与您对领域的理解“同步”的模型。实际的实现模式就是实现细节。例如，我们可以尝试是否有更好的命令表达方式，例如 SetProjectAsActiveCommand -> ActivateProject； AddCommentToProjectCommand -> CommentOnProject。我们摆脱了开发人员语言(set、add、command)，转而使用领域语言。

在这种方法中，命令什么都不做(它们不像 GoF 命令)。它们只是消息，代表用户的意图。聚合(和实体、值对象……)代表我们的结构域模型。他们知道如何做事、做出决策、保护业务规则……在这些消息和决策制定之间，需要有一些东西来接收消息并将其转换为域模型。这些是命令处理程序:它们相当愚蠢，它们只是确保消息到达正确的聚合。很多时候，命令处理程序只是从存储库中获取聚合并告诉它做某事，而不了解内部结构。这巧妙地将命令与域模型分离。

您可能会说我是这种代码组织风格的忠实粉丝。我认为这对 DDD 非常有用。您可以通过许多其他方式应用 DDD。最后，目标不是“做 DDD”，而是构建解决问题、可测试、可维护和可演化的系统。