温故知新——领域驱动设计

我是一个着迷于产品和运营的技术人，乐于跨界的终身学习者。欢迎关注我的个人公众号「跨界架构师」

每周五11：45 按时送达

我的第「225」篇原创敬上

大家好，我是Z哥。

这两天正好有空，花了一下午的时间重新翻阅了一遍《领域驱动设计精粹》，结合最近一阵子的新项目开发，有了一些新的感受和理解。这就是所谓的“温故而知新”吧，在这里分享给大家。

分享的这些点，大多是在践行「领域驱动设计（DDD）」时的关键点，有助于「DDD」的落地。

/01 用「通用语言」描述业务场景/

很多人觉得 DDD 很难落地的一个原因在于，团队中的所有人是否能够对核心概念形成共识。

有一个很棒的方法是，平时要尽可能用「通用语言」来进行沟通，并用于达成共识。

书中有一个示例很棒：

允许将每一个「待办项」【提交】到某个「冲刺」中。只有「待办项」位于「发布计划」中时才能进行【提交】。对于已经提交过的「待办项」如果想【再次提交】到另外一个「冲刺」中，需要先将其【回收】。{提交完成时}，通知相关方【取消提交】的「冲刺」与【准备提交】的「冲刺」。

你看，这里面很清楚地表达了有哪些领域模型、操作、领域事件，以及它们之间的关系。

我用【】标注了操作，「」标注了领域模型，{}标注了领域事件。

显而易见，在团队中用这样的方式进行对齐，对于 DDD 的落地是非常有益的。

/02 不同定位的「子域」侧重点/

「子域」属于业务「领域」的一部分。它与「限界上下文」的不同之处在于它更多是从技术角度去拆分「子域」，而「限界上下文」则是从业务角度去拆分的。

根据「子域」的定位可以划分为三大类：核心域、支撑子域、通用子域。

核心域很显而易见，是重中之重，大多数时候我们的精力都投入在这里。

对于支撑子域，我们不需要过多考虑可扩展性和兼容性，但是却要特别注重可替代性。因为支撑子域是次要的，对整个项目的成败影响很小。往往可以通过外包等方式通过外部资源来解决，并且可以随着规模的发展而进行替换或升级。

对于通用子域，主要关注的是稳定性和兼容性，因为它们有可能被多个领域使用。通用的软件往往市面上也会有很多成熟的产品，我们可以通过购买的方式来快速获得它们。但是在评估它们的时候，记得着重关注稳定性和兼容性。

/03 增强事件和反向查询/

多个「限界上下文」之间的数据传递，无非两种，一种是由数据的生产方通过 MQ 主动传递，另一种是由数据的需要方通过 RPC 反向查询。

可能很多人对于这两个方案该如何选择有点搞不明白。

书中提到的一个思路很棒，概括地来说就是：如果你希望数据的消费者有更多地自治权，那么就选择增强事件。而如果你的消费者有很多，并且不同消费者对关心的数据差异又比较大，那么用轻量的事件配合灵活丰富的查询 API（比如 GraphQL）更适合。

/04 值对象不仅仅是“不可变”/

相信只要对 DDD 有些了解的小伙伴应该都知道「值对象」的「不可变性」。但可能很少人能描述出它的真正作用。

「值对象」的作用是：描述、量化或者测量一个实体。

/05 避免过度抽象/

代码里的抽象和现实生活中的抽象其实是一样的，从本质上来说，抽象可以是无止境的。但是，越抽象，理解的成本就越高。

在 DDD 这种崇尚代码会说话，能表达业务的编程理念中，我们就得避免过度抽象了。过度抽象一个很常见的信号是：为了两个大多数属性字段相同的模型能复用，通过 Type 来区分在不同场景下的不同含义。

/06 如何定义聚合的边界/

每个聚合需要设计得恰好好处，才能既不过度耦合，又能避免事务颗粒度过大。

我们可以用下面的思路来进行，分为两步：

1.先定义用来识别和查询聚合的字段/属性。

2.再填充用于构造聚合并使之处于有效初始状态的内在属性。

/07 用「事件风暴」加速领域设计/

领域模型、领域事件等的设计需要花很多时间讨论、打磨、再沉淀下来。书中分享了一种方式——「事件风暴」。

介绍这个部分的篇幅比较长，但是非常建议大家自己去看一遍。简单概括下来实践事件风暴分为以下几个步骤：

1.定义事件

2.定义操作（命令）

3.设计聚合

4.识别限界上下文和数据流向

5.构思操作人的使用场景和UI设计

另外，在事件风暴中讨论出来的概念，可以根据简单、适中、复杂来进行开发时间的预估。由于颗粒度足够细，还是很有参考价值的。并且当这些概念都一一实现之后，整个系统开发也就完成了。

好了，Z哥这次的收获就是这些，希望对你有所帮助。

最近几年，DDD 被越来越多地的提到，说明在当今软件系统越来越复杂的背景下，更适合 DDD 发挥它的价值。强烈推荐每一位开发者去学习它、掌握它。