领域驱动设计，这十个错误你犯了吗？｜技术杂谈

Posted 2021-05-01 InfoQ

题图：《大圣归来》

Daniel Whittaker在最近的一篇帖子中表示：在进行领域驱动设计（DDD）时，缺乏与领域专家的互动是一种常见的错误，而如果能够尽早发现并解决这一问题，或许能够避免团队无谓的时间浪费。在这篇帖子中，Daniel共列举了十种他发现开发者经常会犯的错误。

01｜让持久化或数据存储问题影响模型的设计。

通过使用战术模式，例如聚合根，能够简化模型，并将相关概念与对基础设施的关注面相互分离，例如数据存储等等。如果在没有经过与领域专家进行交流的前提下贸然开始数据架构或数据模型的设计，可能会导致所创建的代码是基于某个关系型模型，而不是基于某个领域模型的。而在类似话题上，Stefan Tilkov也在先前的一篇文章中对于在企业中使用标准化数据模型的方式提出了警告，这种方式可能会导致模型中充满了可选的特性以及奇怪的行为。

02｜缺乏与领域专家的交流。

DDD的核心实践之一就在于通过与领域专家进行交谈，从而以他们的角度对于问题领域进行理解。而行为驱动开发（BDD）实践则强调与领域专家通过对话的方式创建行为的实例。对此，Konstantin Kudryashov曾专门写过一篇如何将BDD与DDD实践相结合的文章。

03｜忽视领域专家的语言。

DDD的另一个核心实践在于创建一套通用语言，并与领域专家共享。这套通用语言必须使用在讨论过程中，同样也必须反映在代码中，例如类与方法的名称。

04｜没有鉴别出边界上下文。

解决复杂问题的常见方式是将其分解为多个小问题。而边界上下文就是为了将一个大的领域分解为多个小的子领域而出现的，每个边界上下文将负责处理领域中的一个内聚的功能。这一点同样也是微服务的核心概念，在今年的DDD Exchange大会的主题演讲中，Eric Evans专门对此展开了讨论。

05｜使用贫血模型。

这是一个说明团队并没有正确地使用DDD的信号，也暗示着建模过程的失败。一个贫血模型第一眼看上去与真正的领域模型非常相像，例如它们同样使用了正确的名称。但问题在于贫血模型中的类几乎丢失了所有的行为，而变成了只包含单纯的getter与setter属性的容器。

Whittaker所认识到的另外五种常见的错误在于：

06｜没有让边界上下文随着对领域的见解加深而相应地作出改变。

07｜将所有逻辑都设想为领域逻辑。

08｜过度使用集成测试。

09｜将安全性视为领域的一部分（除非你本身设计的就是一种安全性领域）。

10｜过度关注基础设施。

Whittaker最提到的最后一个错误则是忽视了事件风暴的作用，这是由Alberto Brandolini所创建的一种专注于事件的设计过程。Brandolini的想法是，通过将所有的项目干系人都集中在一个房间内，为他们提供无限的空间进行建模工作，并让他们用贴纸的方式写出所有的领域事件。这种方式在几个小时之内就能够为某个问题领域创建出一套非常出色的模型。

▣ 版权归属InfoQ，禁止私自抄袭转载。

回复关键词：React | 架构师 | 运维 | 云 | 开源 | 物联网 | Kubernetes | 架构 | 人工智能 | Kafka | Docker | Netty | CoreOS | QCon | Github | Swift | 敏捷 | 语言 | 程序员

有话想说？！戳“写评论”