架构师训练营第十周作业

根据微服务框架 Dubbo 的架构图，画出 Dubbo 进行一次微服务调用的时序图。

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

组件设计原则

组件设计原则包括：共同封闭原则、共同重用原则、重用发布等价原则、无循环依赖原则、稳定依赖原则、抽象依赖原则。

这些原则是 SOLID 原则在组件粒度上的应用，可以帮助我们判断组件的划分、组件之间的依赖是否合理。我们在分析、验证一个设计方案时，这些原则应该作为我们评审的 checklist 的一部分。

和 SOLID 原则类似，我们无法直接从这些原则获得线索，获得需要的拆分结构。我们从需求开始设计架构时，架构模式、领域模型才是我们的主要抓手。

领域驱动设计

领域驱动设计包括战术设计和战略设计。战略设计主要是确定子域和边界上下文，定义边界上下文之间的关系；战术设计则主要包括：根据业务领域建模；在代码层面有效实现领域模型，将领域模型同技术解耦。

目前的 DDD 在战术层面是完备的，可操作的。它确实带来了 DDD 宣称的好处：分析、设计和实现时，以统一的方式（领域模型）呈现业务逻辑。我个人一直坚持领域建模，以模型指导编码，这种开发模型一个明显的好处就是大大提高了代码的可测试性。

但是在战略层面，DDD 定义了子域、边界上下文，阐述了为什么要合理的子域和上下文，给出了一些实现上下文交互的原则。但可惜这些内容还远远不够。子域、上下文和具体的编码实现相比，意义更重大，难度也更高，要得到它们，需要进行业务建模、需求分析以及架构设计多个软件工程活动，而要有效开展这些活动，作为开发人员，需要得到一个系统性的指导，说明 who、when、what、why 和 how 的问题。我觉得在这些方面，其他一些专门讲述需求管理、软件架构的书籍和资料的价值更大。

中台架构

我认为中台架构和软件架构属于不同层面的架构。

软件架构是指对一个边界确定的软件系统进行分解、得到其内部结构。对一个企业或者组织来说，这个软件系统和其他的软件系统互相交互，共同承担企业对客户的价值。

和软件架构相比，中台架构不是针对特定系统，而是回答企业包含哪些系统，这些系统之间的关系等问题。要得到中台架构，我们需要把整个企业、整个业务作为研究对象。

中台架构属于企业架构范畴，虽然有些通用的原则（比如：高内聚、低耦合）对企业架构和软件架构都适合，但是企业架构有另外一套方法论，比如：TOGAF。