微服务架构谈(4) plus:DDD 分层架构如何推动架构演进

DDD 分层架构的重要原则

在《实现领域驱动设计》书中提到，DDD 分层架构有一个重要的依赖原则:“每层只 能与位于其下方的层发生耦合。”

根据耦合的紧密程度可以分为两种架构模式:严格分层架构和松散分层架构。

严格分层架构是指任何层只能对位于其直接下方的层产生依赖，而松散分层架构则允 许某层与其任意下方的层发生依赖。从图 10-1 我们可以看出，优化后的 DDD 分层架构模 型就属于严格分层架构，而传统的 DDD 分层架构则属于松散分层架构。

那在设计时，我们应该选择什么样的架构模式呢?

综合我的经验，为了服务调用的可管理，我建议你采用严格分层架构，具体原因会在17.1 节详细介绍。

微服务架构的演进

业务和技术都不是一成不变的，领域模型也会随着业务发展不断变化和演进，而领域 模型的演进又会直接影响微服务的功能和边界。那如何实现领域模型和微服务的同步演进 呢?下面我们将从两方面展开详细分析。

在 DDD 的领域层主要有:领域服务、值对象、实体、聚合根和聚合等。一般来说实体 或值对象的简单变更，不会让领域模型和微服务发生太大变化，但聚合的重组或拆分却可 以。这是因为聚合业务功能内聚，能独立完成特定业务领域的业务逻辑。所以聚合重组或 拆分，势必会引起领域模型和微服务的系统功能变化。

这里我们可以以聚合作为组合和拆分的基本单元，完成领域模型和微服务架构的演进。我们可以将聚合作为一个完整单元，在不同的领域模型之间完成重组或者拆分，甚至可以 直接将一个聚合独立拆分为微服务。

下面结合图 10-3，以微服务 1 为例，讲解微服务架构的演进过程。

当你发现微服务 1 中聚合 a 的业务功能经常被高频访问，以致拖累整个微服务 1 的性 能时，可以将聚合 a 的代码整体从微服务 1 中剥离出来，独立为微服务 2。这样微服务 2 就 可轻松应对高性能需求的业务场景了。

在业务发展到一定阶段以后，你发现微服务 3 的领域模型有了变化，聚合 d 更适合放 到微服务 1 的领域模型中。这时你就可以将聚合 d 的代码整体搬迁到微服务 1 中。如果你 在微服务设计时，已经提前定义好了聚合之间的代码边界，那这个代码搬迁的过程就不会 太复杂，也不会花太多时间。

最后我们发现，在经历领域模型和微服务架构演进后，微服务 1 已经从最初包含聚合a、b、c，演进为包含聚合 b、c、d 的新微服务了，而微服务 1 中的聚合 a 也已经独立成微服务 2 了。

</