微服务、中台和 DDD

微服务、中台、DDD 都是当今流行的架构概念。那他们有什么联系呢？



可以从这个三个问题入手，了解他们之间的联系：

• 他们从哪里来？

• 他们到哪里去？

• 他们是如何联系起来的？



从哪里来

中台

中台是企业级能力复用平台。



中台来自于业务部门的序曲。业务部门的口碑，是数据部门的生命线。

要解决业务的问题，得先搞清楚业务存在哪些问题。这些问题归结为两类：

• 第一类是数据用的好不好的问题；

• 第二类是怎么让数据帮助业务解决更多的问题。

微服务



单体应用在变得越来越臃肿后，会遇到编译、部署困难，代码分支管理困难，数据库连接耗尽，新增业务困难，发布困难这些现实难题。这是微服务诞生的基础环境。



“在企业内部将服务有组织地进行拆分”这个理念则脱胎于 SOA（Service Oriented Architecture，面向服务的架构），只不过，SOA 诞生自那个大企业操盘技术的年代，自身太过于复杂，没有真正流行开来。而微服务由于自身更加轻量级，符合程序员的胃口，才得以拥有更大的发展空间。

DDD

市面上很多介绍微服务的内容，基本上都是在讲工具的用法，或是一些具体技术的讨论，比如，用 Spring Boot 可以快速搭建服务，用 Spring Cloud 建立分布式系统，用 Service Mesh 技术作为服务的基础设施，以及怎么在微服务架构下保证事务的一致性，等等。确实，这些内容在你实现微服务时，都是有价值的。但必须先回答一个问题，我们为什么要做微服务？



对这个问题的标准回答是，相对于整体服务（Monolithic）而言，微服务足够小，代码更容易理解，测试更容易，部署也更简单。



这些道理都对，但这是做好了微服务的结果。怎么才能到达这个状态呢？这里面有一个关键因素，怎么划分微服务，也就是一个庞大的系统按照什么样的方式分解。



那应该怎么划分微服务呢？你需要了解领域驱动设计（ DDD ）。



DDD 最为基础的就是通用语言（Ubiquitous Language），让业务人员和程序员说一样的语言。

把不同的概念分解出来，这其实是限界上下文（Bounded Context）的作用，而在代码里尽可能使用业务语言，这是通用语言（Ubiquitous Language）的作用。



微服务真正的难点并非在于技术实现，而是业务划分，而这刚好是 DDD 战略设计中限界上下文（Bounded Context）的强项。



到哪里去

中台

数据中台的价值最终是要回到业务价值上来的。对数据部门的负责人来说，最尴尬的地方，就是数据中台并不能直接产生业务价值，他们需要前台（也就是数据应用）来接触业务，所以数据中台的价值，最终还是要通过数据应用来体现。

• 数据需求的交付时间到底有没有缩短；

• 还存不存在指标业务口径不一致的问题；

• 数据质量是否有显著的提升；数据成本是否增长变慢了。



中台化是平台化的下一站，是平台不断对于自身治理演进、打破技术边界、逐渐拥抱业务、容纳业务、具备更强的业务属性的过程。中台关注为前台业务赋能，真正为前台而生。

微服务

实践微服务的选择需要遵循一个倒三角模型：





首先明确自己的需求：我们到底想用微服务达到什么样的目的？需求清晰了，再去考虑具体要实现的价值，再根据价值构建我们的设计原则，根据原则寻找最佳实践，最后根据实践去选择最合适的工具。

如果相反，先找到一个工具，然后用工具硬往上套需求，只会导致技术也没用好，业务也没做好，所有人都疲惫不堪，事情变得一团糟，最后反过来怪技术没用。

DDD

在《实现领域驱动设计》⼀书中，Vernon 不仅对整个领域驱动设计过程作了⼀番有益的梳理，还结合社区发展在书中引⼊了六边形架构和领域事件等概念，领域驱动设计并不是⼀套死板的⽅法，⽽是⼀种设计思想、⼀种开放的设计⽅法体系，只要有利于领域驱动设计的实践，都可以引⼊其中。⼤胆地引⼊⽤例、敏捷实践、整洁架构，为领域驱动设计提供补充。

Eric Evans 的《领域驱动设计》是以⾯向对象设计作为模型驱动设计的基础，但时下被频繁运⽤的函数式编程思想也给模型驱动设计带来了另⼀种视⻆。从开放的设计⽅法体系的⻆度讲，我们完全可以把更多的编程范式引⼊到领域驱动设计中。因为有了更多的选择，针对不同的业务场景就可以选择更适合的DDD 实践，⽽不仅仅限于 Eric Evans 最初提出的范畴。



如何联系

中台是抽象出来的业务模型，微服务是业务模型的系统实现，DDD 作为方法论可以同时指导中台业务建模和微服务建设，三者相辅相成，完美结合。



DDD 有两把利器，那就是它的战略设计和战术设计方法。中台在企业架构上更多偏向业务模型，形成中台的过程实际上也是业务领域不断细分的过程。在这个过程中我们会将同类通用的业务能力进行聚合和业务重构，再根据限界上下文和业务内聚的原则建立领域模型。而 DDD 的战略设计最擅长的就是领域建模。那在中台完成领域建模后，我们就需要通过微服务来完成系统建设。此时，DDD 的战术设计又恰好可以与微服务的设计完美结合。可以说，中台和微服务正是 DDD 实战的最佳场景。



参考

https://time.geekbang.org/column/article/185352

https://time.geekbang.org/column/article/140065

https://time.geekbang.org/column/intro/100036501

https://time.geekbang.org/column/article/161004

https://time.geekbang.org/column/article/89049

https://time.geekbang.org/column/article/82581