为何大佬喜欢用聚合当领域设计的基本单元

一、背景

今年在DDDChina上认识了很多行业大佬，也跟着学习了一波，在领域建模的过程中关于实体，值对象和聚合的讨论比较多，也看了一些大佬的书。在大佬眼力进行领域模型设计的时候把聚合当作基本单元看着是比较随意的事情，但是对于初学者来说可能还需要一些时间消化。这里来简单探讨下整个问题。

二、聚合与统一语言

我想到这个问题的相关情况就是这个聚合或者聚合根一定是从统一语言出来的，但是统一语言里那么多词语短句，也不是随便一个就能拿过来当聚合的。在中文的视角下一个词可以代表一个整体的事物，所以如果识别了统一语言中的这个领域的一些重要的词语就相当于找到了一个切入点，顺带把其他的统一语言给消化掉。

三、聚合与抓手

这里将聚合和聚合根当作一个抓手或者切入点来构建整个项目骨架或者上下文骨架。在我这边有限的建模和实战经验看一个中型复杂度的项目里可能就十来个模块，每个模块最多估计有1-2个聚合，所以从这里可以看出聚合仍然是从模块和包的角度来构建整个项目的核心内容。

四、聚合与上下文

在领域驱动设计里聚合，模块，上下文和 领域都是一环套一环的，所以在建模过程中这个聚合可能代表某种上下文。比如库存，在库存这个聚合中肯定包括了一些商品，仓库等信息，那就是说这个聚合呈现的是一个业务中的某个上下文。

五、聚合与隐喻

我们从统一语言中看到的都是已经显示表达过的事情或者被我们总结过了，那有时候可能因为识别不到位导致存在没有表达的东西或者过多表达聚合的内容，这就相当于有些隐喻内容我们没有正确的识别到，如果这种情况比较严重，那么在设计聚合的时候就可能产生严重的后果。

六、打破聚合的场景

上面是我从之前的学习文档中截图的，可能不是特别容易理解。正是因为我们在实际情况中在设计领域模型的时候会容易受到很多干扰导致聚合根和聚合不够合理，在代码模型上也显得别扭，所以不太好理解大佬说的聚合当作领域设计的基本单元。那现在具体看一下有哪些打破聚合的场景。

6.1 方便用户界面

有时候因为用户界面的设计在领域看来是跨了多个聚合根，严重的情况下会跨领域，所以为了方便用户界面，在后端进行数据处理的时候很容易需要管理多个模块下的数据对象，从而在设计的过程中就会因为用户界面的设计让接口参数变得臃肿，同时让聚合更加难以识别。

6.2 缺乏技术实现机制

这种情况可能就因为业务不太复杂或者并发量不高，不太容易出现一致性问题，所以是否聚合或者要不要识别到聚合已经不是特别重要。对于业务系统的复杂度相对可控。

6.3 全局事务一致性

在设计聚合的时候我们也会因为事务让聚合变得相对较小，一方面因为技术因素，另外一方面也因为聚合小方便管理，那么一旦出现性能或者严格的场景下需要全局事务的话，就是大的聚合操作了，那这样的话识别聚合在受到事务要求的情况下也会变得不可控。

6.4 查询性能原因

这个原因比较常见，比如用户界面回显数据，或者查询整个领域内部的某条记录相关的全部记录数据等等。那在此时的话跟写相关的聚合设计与查询就不是特别一样了，因为查询可能会相对个性化，查询频率也很高，我们不得不引入更多的技术来保障查询和写之间的一致性。

七、总结

1. 把聚合当作领域设计的基本单元就好比在统一语言上撕开几个口子，尺度不大也不小。
2. 我们可以根据识别到的聚合来分别构建适合读和写的聚合模型。