1. 题目一：Dubbo微服务调用时序图





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

2.1 DDD、中台架构及组件设计原则的相互关系



DDD可以通过它的战略设计和战术设计方法指导中台和微服务建设。



中台在企业架构上更多偏向业务模型，形成中台的过程实际上也是业务领域不断细分的过程。在这个过程中我们会将同类通用的业务能力进行聚合和业务重构，再根据限界上下文和业务内聚的原则建立领域模型。而 DDD 的战略设计最擅长的就是领域建模。



在中台完成领域建模后，我们就需要通过微服务来完成系统建设。此时，DDD 的战术设计又恰好可以与微服务的设计完美结合。

2.2 DDD的本质

在研究和解决业务问题时，DDD 会按照一定的规则将业务领域进行细分，领域细分到一定的程度后，DDD 会将问题范围限定在特定的边界内，并在这个边界内建立领域模型，进而用代码实现该领域模型，解决相应的业务问题。领域可分解为子域，子域可继续分为子子域，一直到你认为适合建立领域模型为止。





子域还会根据自身重要性和功能属性划分为三类子域，它们分别是核心域、支撑域和通用域。





通过领域划分和进一步的子域划分，我们就可以区分不同子域在企业内的功能属性和重要性，进而采取不同的资源投入和建设策略。



2.3 中台的本质

中台的本质其实就是提炼各个业务板块的共同需求，进行业务和系统抽象，形成通用的可复用的业务模型，打造成组件化产品，供前台部门使用。前台要做什么业务，需要什么资源，可以直接找中台，不需要每次都去改动自己的底层。



传统企业可以将需要共享的公共能力进行领域建模，建设可共享的通用中台。除此之外，传统企业还会将核心能力进行领域建模，建设面向不同渠道的可复用的核心中台。





如果将企业内整个业务域作为一个问题域的话，企业内的所有业务就是一个领域。在进行领域细分时，从 DDD 视角来看，子域可分为核心域、通用域和支撑域。从中台建设的视角来看，业务域细分后的业务中台，可分为核心中台和通用中台。



2.3.1 中台建模五步

中台业务抽象的过程就是业务建模的过程，对应 DDD 的战略设计。系统抽象的过程就是微服务的建设过程，对应 DDD 的战术设计。



1. 按照业务流程（通常适用于核心域）或者功能属性、集合（通常适用于通用域或支撑域），将业务域细分为多个中台，再根据功能属性或重要性归类到核心中台或通用中台。核心中台设计时要考虑核心竞争力，通用中台要站在企业高度考虑共享和复用能力。







1. 选取中台，根据用例、业务场景或用户旅程完成事件风暴，找出实体、聚合和限界上下文。依次进行领域分解，建立领域模型。



1. 以主领域模型为基础，扫描其它中台领域模型，检查并确定是否存在重复或者需要重组的领域对象、功能，提炼并重构主领域模型，完成最终的领域模型设计。



1. 选择其它主领域模型重复第三步，直到所有主领域模型完成比对和重构。



1. 基于领域模型完成微服务设计，完成系统落地。



2.4 软件组件设计原则

• 组件内聚原则：哪些类应该聚合在同一个组件中，以便组件能提供相对完整的功能，又不至于太过庞大



• 复用发布等同原则：软件复用的最小力度应该等同于发布的最小粒度

版本号约定：主版本号.次版本号.修订号

主版本号升级：组件发生了不向前兼容的重大修订

次版本号升级：重要功能修订或bug修复，组件前向兼容

修订号升级：不重要的功能修订或bug修复



• 共同封闭原则：将那些会同时修改，并且为了相同目的修改的类放到同一个组件中。否则放到不同组件中。



• 共同复用原则：不要强迫一个组件的用户依赖他们不需要的东西。应该将相互依赖，共同复用的类放到一个组件中，以使这个组件中的类共同对外提供服务。如果不是被共同依赖的类，不应该放在同一个组件中，否则如果不被依赖的类发生变更引起组件和使用组件的程序发生不必要的变更。



• 组件耦合原则：组件之间的耦合关系应该如何设计



• 无循环依赖原则：组件依赖关系中不应该出现环



• 稳定依赖原则：组件依赖关系必须指向更稳定的方向。较少变更的组件是稳定的。不稳定的组件应该依赖稳定的组件。



• 稳定抽象原则：一个稳定的组件应该是抽象的，不稳定的组件应该是具体的。如果你设计的组件是具体的，不稳定的，那么可以为这个组件对外提供服务的类设计一组接口，并把这组接口封装在一个专门的组件中，那么这个组件相对就比较稳定、抽象。（适配器模式？）



• 组件的边界与依赖关系，不仅仅是技术问题：还要考虑业务场景、职责边界、公司政治关系。