第2章 微服务领域驱动设计

近几年来，微服务架构风格逐渐成为软件业的宠儿，并在大多数新兴的业务场景中得到运用，同时，我们发现另外一种设计方法总会与微服务携手同行，这就是领域驱动设计（Domain Driven Design, DDD）。一个是架构设计的弄潮儿，另一个是默默耕耘的经典方法，它们之间是怎么碰撞出“感情火花”的呢？

我们谈论微服务，看重它的“微”带来的灵活、弹性、易维护、可替换等诸多便利；同时却要看到：服务的细粒度分解固然减小了系统的规模，却又会因为显著增加的服务数量使系统结构变得更加繁杂。显然，微服务架构实则是通过牺牲“结构”换来“规模”的红利。

从结构这个维度看，微服务其实一点都不“微”！一个微服务从诞生到最后的消亡，经历了设计、开发、测试、上线、运行到下线贯穿始终的生命周期。当一个系统包含成百乃至上千个微服务时，系统的结构会变得越来越复杂。每个环节都有方方面面的因素需要考量，诸如设计原则的遵守、通信机制的选择、数据一致性的保障、健康状态的监控与跟踪，乃至于服务的配置、测试与运维。这些都是运用和实施微服务的重要关注点，它们更多来自技术层面的考量，我称其为微服务的“技术维度”。

基于“微服务”的定义，在这个架构风格中，每个服务都是独立运行（standalone）的微小服务，这意味着微服务的边界为完全独立的跨进程通信边界。这就带来一个至关重要的核心问题：如何设计和分解微服务？从粒度看，如果服务分解过细，则会增加通信成本和运维成本；如果服务分解过粗，那么又达不到单独伸缩和运维的目的。从职责分配看，由于微服务粒度比单体架构更细，且牵涉跨进程的通信边界，一旦职责分配有误，调整的成本要远远大于单体架构。故而在微服务架构风格下，微服务的设计与分解有可能成为整个系统在未来的“阿喀琉斯之踵”。针对微服务架构，普遍达成的共识是从业务角度驱动服务的识别与分解，我称其为微服务的“业务维度”。

技术维度的关注点，我们交给基础架构的设计者及微服务的框架来保障。至于业务维度的关注点恰好是领域驱动设计所擅长解决的。这就是为什么在谈到微服务时，我们需要领域驱动设计的原因。