11

对于这里和其他论坛提出的很多问题，我看到的一个常见反应是“你不需要为此做 DDD。它是一个简单的 CRUD 应用程序，DDD 是一种过度工程”。

好吧，我是 DDD 的新手，我觉得 DDD 中有很多元素具有普遍的吸引力，可以全面使用，无论您的应用程序是否复杂，都需要强制 DDD。例如，应用程序的分层、DDD 识别的不同工件等。可能从基础开始，公认的贫乏模型，然后朝着尽可能多的纯度工作/重构。

这种方法听起来不错吗？
或者您会说每个应用程序的设计都有一个基本选择，即是否采用 DDD 方式，一种“全有或全无”的选择？

更新 （提供更多上下文，以回应休在下面的评论）
  我正在围绕现有的 RuleEngine 类型的应用程序构建一个 webapp，基本上是 CRUD 和一些验证、不变量，然后是部署过程。规则编写和语义检查是由我作为 CRUD 的一部分调用的独立代码完成的，并且在我的代码中没有任何特定于语义的逻辑。我正在尝试将 DDD 用于此应用程序，但我发现它可能不够复杂，无法适应 DDD 范例。没有为该领域定义普遍存在的语言，即除了命名所涉及的实体集之外，该语言还不够专业。我听到我的领域专家谈论创建、编辑、删除实体。

4

3 回答 3

6

DDD 不是全有或全无。此外，DDD 中描述的许多模式都不是新的，到处都可以找到。Eric Evans（DDD 书的作者）只是将它们组装起来，在需要的地方将它们形式化，并将它们相互关联。您可以自由使用适合您的问题空间的内容。

经常被忽视的：DDD 描述了实现模式和分析模式。分析模式在许多（如果不是大多数）应用程序中可能是多余的，但实现模式（即实体、规范、服务）在不太复杂的场景中也很有用。

于 2012-08-07T13:48:20.060 回答
4

In short,

If it's just CRUD, I wouldn't bother.

On the other hand,

If it's got behavior, where the next state of something relies on the previous state, then DDD is something you probably want to consider.

于 2012-08-07T13:41:11.640 回答
0

DDD 方法基于两种类型的模式：战略模式和战术模式。恕我直言，在您确定会有所帮助的每种情况下都可以自由使用战术模式。但是对于某些类型的域来说，使用战略模式可能是多余的。如果 CRUD 风格的思维，在建模过程中没有负面影响，你肯定不需要它。

于 2019-10-24T12:24:15.877 回答