您是否犯了领域驱动设计这 10 个错误？
5.00/5 (6投票s)
您是否犯了领域驱动设计这 10 个错误？
引言
犯错误是编程的一部分。尽早发现它们可以为您节省时间。我开始注意到许多人都似乎会犯一些常见的“领域驱动设计错误”。是的，我职业生涯的某个阶段都犯过这些错误。这绝非最终列表——我敢肯定还有更多（滚动到文章底部查看信息图）。
1. 让持久化和数据库影响模型
在遵循 DDD 方法时，这是一个常见的“错误”。许多战术模式（如聚合根）旨在简化模型。它们通过将解决方案与数据库等基础设施关注点隔离来实现简洁。DDD 方法的真正起点始终是领域专家。如果您发现自己从模式或数据模型开始，那应该敲响警钟了。最终解决方案可能最终使用存储过程而不是关系模型。但数据库不应参与建模的早期阶段。
2. 没有深入了解领域专家
领域建模的核心在于弥合沟通差距的愿望。您对问题域的理解越深，您的解决方案就越好。我所说的“理解问题”是指从领域专家的角度来看。因此，如果您正在为一个电路板测试系统建模，请花时间与电子工程师一起工作。如果这是一个飞机加油协调系统，请花时间与加油协调员（或他们称为什么）一起工作。
3. 忽略领域专家的语言
DDD 的一个关键概念称为“通用语言”。这个想法很简单。首先要理解专家的语言。然后将领域专家的语言融入您所有的代码和讨论中。一直到方法、类和变量的名称。
健康警告：通用语言仅在有界上下文内是通用的。例如，“客户”一词在会计 BC 中可能与仓库 BC 中的含义不同。
4. 未识别有界上下文
您如何解决一个复杂的问题？一种常见的方法是将其分解成更小的部分。隔离和解决小问题更容易解决大问题。这是有界上下文的关键好处之一。识别它们直接影响构建成功解决方案的可能性。
5. 尽管有了更深入的领域见解，仍维持有界上下文
当您找到一个似乎有效的上下文时，很容易坚持下去。但这种僵化会成为一个问题。领域发现过程是随着时间推移而演变的。您的代码应该随着这些发现而演变。要做到这一点，您的代码需要具有灵活性。您需要用正确的测试来覆盖您的代码。这使您能够自由地重构代码以反映这些发现。它允许您利用对域不断增长的理解。
6. 使用贫血的领域模型
这是建模过程出错的常见症状。这也是您没有做“DDD”的标志。但什么是贫血的领域模型？它是充满公共属性以及 getter 和 setter 的领域类。它们是没有任何自身行为的类。由于 ORM 将数据库模式映射到代码，因此这些类变得普遍。您的系统中可能仍然存在这类类，但它们不是您的领域对象。而是寻找封装对象并提供行为。
7. 假设所有逻辑都是领域逻辑
这又是一个常见的错误。假设是所有逻辑都是领域逻辑。您可能会在试图将所有内容硬塞到您的领域模型中时陷入困境。最明显的例子是表单上的字段验证。大多数字段验证逻辑应靠近客户端代码。在 Web 应用程序中，它会在 JavaScript 和端点控制器中。例如，验证电子邮件或必填的名字字段。混淆源于我们试图将所有验证逻辑保存在一个地方。例如，我们可能会检查年龄是否在特定范围内。这是字段验证。而确保一个人有足够的年龄来处理危险品，这是一个领域关注点。其他类型的“逻辑”也可能不适合放在领域对象中。一个例子是当一个聚合仅用于容纳一个应该涉及多个聚合的过程时。更好的方法是使用流程管理器。这将处理流程逻辑，而聚合则处理实现逻辑。
8. 过度使用交互测试
保持代码的灵活性非常重要。这在早期阶段尤其如此。但要允许进行大规模重构，您需要一个安全网。这个网是一套良好的测试。它们应该有助于开发过程，而不是成为绊脚石。我注意到交互测试倾向于阻碍重构。这是因为交互测试期望已调用某些方法。它确保这些方法以特定参数等方式被调用。问题在于。如果我们改变工作方式，但不是最终结果，测试就会失败。一种更健壮的测试机制是通过检查最终状态。给定一个特定场景，当收到特定输入时，预期会产生特定的最终状态。这里的关键是测试不关心状态是如何达到的。这使您可以随意修改内部结构，并确信系统仍然正常运行。
9. 将安全视为领域的一部分（除非实际上是）
安全性是我们今天构建的许多系统的重要组成部分。然而，它很少是领域的一部分。计算风险的结果不会因计算者是超级用户还是普通用户而改变。因此，虽然安全性是系统的重要组成部分，但不应将其纳入领域建模。除非它实际上是领域的一部分！
10. 关注基础设施
我已经在开头提到了在开始时关注数据库的常见错误。另一个错误是在建模阶段关注基础设施问题。一个例子是从设备获取数据流。您应该为您的系统定义数据的形状。然后使用适配器确保任何为您提供数据的服务都被转换成正确的格式。
如果这一切还不够，这里还有一个额外的……
奖励：11. 跳过 EventStorming 过程
EventStorming 经常被开发人员忽视。它涉及不同类型的技能。让合适的人进入会议室可能很困难。并且不能保证您会得出有用的结论。我添加它的原因是因为它非常值得做。如果您想加快设计过程。如果您想尽早发现领域中的“表象”。如果您想获得支持。如果您想获得参与。这两者都是成功项目的关键要素。那么不要错过 EventStorm。
健康警告：对于您正在构建的系统，DDD 可能不是正确的方法。在这种情况下，上述建议不一定适用。
