最早是在极客时间知道欧创新老师的，我也是他的课程《DDD实战课》的订阅者，后来欧老师基于这门课程做更多的实践与思考，完成了《中台架构与实现：基于 DDD 和微服务》这本书的写作，最近刚好读完了这本书。
中台、微服务、DDD，这三个都是比较大的概念，每一个在市面上都有很多相关的书籍，一本书想要把三者都介绍得非常深入，不太容易，但本书很好地结合大量的案例将三者串联起来，能够让我们了解更多概念性内容之外，也能指导我们动手进行实践。
从本书的副标题：基于 DDD 和微服务，可以得知：
- 本书是介绍如何采用 DDD 和 微服务的方式来落地中台的架构和实现，是一本偏实践的书；
- DDD 和微服务是相辅相成的，至于为什么，从书中可以找到答案。
中台最早是阿里在 2015 年提出的，具体故事是这样的：
马云当时在芬兰考察一家叫 Supercell 的游戏公司，该公司员工数不到 200，一年的利润却高达 15 亿美金，很重要的原因就是 Supercell 公司把游戏开发中大量重复的工作整理出来，开发成工具供所有人使用，大大提高了效率。马云深受启发，回来后便提出了中台战略。
中台大体分为业务中台、数据中台和技术中台，但其本质都是能力的复用，说起复用，作为程序员的我们就非常熟悉了，抽取公共函数、公共类库、自研一些中间件或者使用开源中间件，都是为了复用提高效率，这样看来，即便我们处在中小公司，「中台」离我们也没那么遥远。
微服务架构是 Martin Flower 大神在 2014 年提出，这个概念针对的是我们常见的单体应用，是为了解决单体应用的一些常见问题：
- 技术栈受限，新技术较难引进；
- 任何修改需整个部署，持续交付周期长；
- 可靠性，一个模块的问题可能导致整个应用的问题。
所以在微服务的架构中，我们可以：
- 解决复杂问题，将复杂的问题分而治之；
- 不同的微服务可以使用不同技术栈，发挥各家之长；
- 独立部署，能更快地迭代，符合敏捷的开发思想。
但，微服务也不是银弹，带来好处的同时，也势必会带来很多的问题，关于问题在后面的微服务系列再详细来讲。
而提到微服务的框架，最容易想到的就是 Spring Cloud，里面包含一堆解决微服务架构的各种问题的组件，比如：
- Eureka：服务发现；
- Feign：微服务之间的远程调用；
- Hystrix：实现熔断和限流；
- Zuul：服务网关；
- Sleuth：链路追踪；
- Connfig：配置中心。
在 dotNET Core 中目前还没有比较成熟的类似 Spring Cloud 这样的全家桶（也可能是我还不知道），但通过一些开源组件一样能够构建微服务系统：
- 服务发现：Consul；
- 链路跟踪：SkyWalking 或 Twitter 的 Zipkin
- 远程调用：Grpc；
- 熔断和限流：Polly；
- 服务网关：Ocelot；
- 配置中心：Apollo；
我们都知道微服务就是要将一个大的应用进行拆分，上面提到的组件都是解决拆分后所带来的的问题，但具体一个复杂应用应该怎样拆分，应该按照什么粒度进行拆分，在微服务架构中并没有很好的指引，这时就需要 DDD 了。
DDD 是一种架构思想，是由著名建模专家 Eric Evans 在 2004 年提出，分为战略层面和战术层面，在战略层面，主要讲的就是如何进行系统拆分。正好弥补了微服务的不足，所以在近些年微服务比较火热的情况下，DDD 也焕发了第二春。
DDD 中引入了很多的名词概念：领域、子域、通用域、支撑域、核心域、领域事件、限界上下文、聚合、聚合根、实体、值对象等。初学者光是弄懂这些概念需要花费很大的功夫，更别提使用 DDD 来进行代码落地了。
在本书中，有关 DDD 我印象很深的就是书中使用桃树做类比来模拟进行领域的分解，将我们熟悉概念和知识类比到 DDD 中陌生的术语，可以快速地帮助我们理解 DDD 中的各种术语。
那么中台，微服务和 DDD 又是什么关系呢？这里引用书中的一张原图：
- 上面的中台可以泛指所有的复杂业务系统，既然是复杂系统就需要分而治之，怎么分？就靠 DDD 中的战略层面的指导思想；
- 分解完后，再集合 DDD 战术层面的思想和微服务的技术框架就能很好进行代码落地了。
市面上很多介绍 DDD 的书籍，即便是在讲战术层面，也很晦涩难懂，看完除了概念更熟悉了点之外，依然不知道怎样进行代码编写。而这正是本书的优势所在，除了有标准的代码模型，还有具体示例的代码详解。这也是我看此书觉得比较惊喜的地方。
看完这本书，我依然不敢说我对中台、DDD 和微服务有多深的了解，但我相信有了这本书的基础，再去阅读 Eric Evans 等大神的著作，应该能收获更多、也会更加深入。
