知识卡片
以聚合为单位驱动微服务架构的重组与拆分演进
内容
领域层里实体或值对象的简单变更,通常不会给领域模型和微服务带来太大冲击,但聚合的重组或拆分会——因为聚合本身业务功能内聚、能独立完成特定业务领域的逻辑,一旦聚合被重组或拆分,领域模型和微服务的系统功能边界也会随之变化。这决定了聚合可以作为架构演进时组合与拆分的基本单元:把聚合当作一个完整的、可移动的积木块,可以在不同领域模型之间重组,甚至直接把一个聚合独立拆分成一个新的微服务。书中给出一个具体场景:当某个微服务里的某个聚合因为被高频访问、拖累了整个微服务的性能时,可以把这个聚合的代码整体剥离出来独立成一个新微服务,专门应对高性能需求;反过来,当业务发展导致某个聚合更适合归到另一个领域模型时,也可以把它的代码整体搬迁过去。这个演进能够顺利进行的前提,是设计之初就已经把聚合之间的代码边界划分清楚——如果聚合边界本身混乱、代码相互交织,这种整体搬迁或拆分就无从谈起,前期投入在聚合边界设计上的成本,会在后续架构演进时以”改动量小、耗时短”的方式收回。
参考来源
- 位置:第10章《DDD分层架构》"10.2.1 微服务架构的演进"(源文件:_epub-src/OEBPS/Text/chapter3-6-2-1.xhtml)
- 结论依据:原文说明"聚合的重组或拆分却可以……这是因为聚合业务功能内聚,能独立完成特定业务领域的业务逻辑……我们可以将聚合作为一个完整单元,在不同的领域模型之间完成重组或者拆分,甚至可以直接将一个聚合独立拆分为微服务……如果你在微服务设计时,已经提前定义好了聚合之间的代码边界,那这个代码搬迁的过程就不会太复杂",直接支撑本卡片结论。
- 原始内容:当你发现微服务1中聚合a的业务功能经常被高频访问,以致拖累整个微服务1的性能时,可以将聚合a的代码整体从微服务1中剥离出来,独立为微服务2。这样微服务2就可轻松应对高性能需求的业务场景了。