架构师训练营 第十周 课后练习

作业

关于微服务架构（中台架构、领域驱动设计、组件设计原则），你有什么样的思考和认识？

我的思考和认识

因为篇幅有限以及自身的特殊原因，我简单谈一下自己在工作实践和学习中针对以上几个概念的几点认识和思考。



针对微服务架构和DDD的业务开发的演变过程大致总结为：需求业务化、业务领域化、领域模块化、模块服务化，详细说明如下：



需求业务化：将线下的业务映射到系统的线上能力；

业务领域化：划分清楚业务的领域边界；

领域模块化：将不同领域的业务代码做到代码级别的物理解耦；

模块服务化：将独立的领域服务对外公开，设计为独立自治的服务，使其达到最大的价值（也就是微服务的价值）。

领域驱动设计

不管是哪种开发方法论，我们都应该关注其本质而非形式，关注其到底解决的是什么样的问题，而不是为了使用DDD而使用DDD。

想要做好DDD的前提是我们关注的是业务概念较为强的系统，如果是一般的信息系统，全系统使用数据库脚本实现都是可行的。

业务系统为什么要使用DDD进行开发？其实这个和为什么要使用面向对象分析和设计是一样的，只有把业务梳理清楚，把业务的边界划分清晰，才有可能把业务模型建立出来；

为什么建立业务模型？因为只有建立了业务模型，才能把某个行业领域的业务沉淀下来，分析清楚业务模型，才知道这个领域中的核心模型的价值是什么，这个和面向对象的理念是一致的，其实业内针对没有方法的对象的使用是非常普遍的，所有的读写都已经退化为在Service端对属性的读取和赋值，这样的代码首先可读性就很差，其次很多核心的业务类将自己的属性通通暴露对外，这些都是没有必要的，按照“谁拥有数据，谁担当职责”的原则，我们完全可以将对象的行为抽象出来，也就是业务模型对象的价值就体现出来了；

为什么行为比属性更加有价值？举个例子，我的杯子是绿色的，我的手机也是绿色的，他们都拥有属性color并且是绿色，但是这个属性并不能区分这个是手机还是杯子，也没有办法体现杯子和手机的核心价值，而行为就不同，手机有行为“给指定的号码打电话”，杯子有行为“盛水”，就可以区分出这两个业务模型，也分别体现了其价值。

领域驱动设计知识体系中有很多的概念，“限界上下文”、“子域”、“实体”、“值类型”、“聚合根”等等，在实际开发过程中，未必每个概念都落实，但是针对于业务模型的抽象是核心必不可少的，没有它，其它做的一切都是只形式主义而已。

微服务架构

当业务领域划分到位后，才会有微服务的构建的可能，当然，要不要使用微服务这个涉及到公司的组织架构的划分、涉及到团队的开发能力以及团队的大小也涉及到微服务的基础设施是否已经完善。

当领域最后走到服务化的时候，项目的业务复杂度已经到了一定的程度，微服务带来的是从业务上的解耦，微服务项目的自治（包括开发和运维），团队可以用自己熟悉的技术栈进行开发甚至可以尝试使用新技术，如今盛行的容器化技术更是为微服务的构建和部署提供了强大的后盾，小而独立的微服务可以通过自动化构建基础设施进行快速的迭代和更新。

中台架构

因为目前的开发经验以及公司规模的限制，并未参与过中台架构的相关设计和开发，我简单谈一下自己对于中台架构的认识。随着一个公司的业务不断的发展，其应用系统可能会出现的演变过程是单体->服务化>平台化，前端涉及到的有APP、H5、Web、小程序等等，后端服务系统支撑着前端的业务，以电商为例，可能会有订单系统、会员系统、交易系统、商品库系统等，但是因为前端的业务迭代的不断加速，后端的支撑开始吃力，而需要一个中间层（智慧老师强调的中间层真的很强大）去将业务的核心能力进行组合，能够通过某种机制或者规则等快速适配前端业务，其实就是将公司的更粗力度的业务线进行整合用来适配前端，形成了中台架构，简单来说就是“企业级的能力复用”。