第十周命题作业

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

原谅我，画图实在很有挑战



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

中台架构：

业务中台，将不同业务线解决相同问题的解决方案进行抽象与封装，通过配置化、插件化、服务化，实现对于不同业务线的业务支撑。

数据中台，对业务产生的数据进行二次加工，其成果再服务于业务。



领域驱动设计：

过去系统分析和系统设计是分离的，导致需求分析的结果无法直接进行编程，而能够进行编程运行的设计却扭曲需求，客户运行软件后才发现很多功能不是自己想要的，而且软件不能快速跟随需求变化。DDD则打破了这种隔阂，提出了领域模型概念，统一了分析和设计编程，使得软件能够更灵活快速跟随需求变化。领域驱动设计的核心理念是分层、分治，要求在做架构设计时，必须时刻区分此刻所处的是问题域空间还是解决方案域空间。业务及其对应的业务架构是软件要解决的问题，所以业务架构处于问题域空间；而软件系统是业务上的解决方案，所以软件架构处于解决方案域空间。

领域驱动设计的核心是领域模型，而领域模型的设计精髓在于面向对象分析，在于对事物的抽象能力。

领域驱动设计的原则包括识别与聚焦核心域、通过协同共创迭代式探索、使用统一语言。



组件设计原则：高内聚，低耦合

👉复用/发布等同原则：保持组件的重用粒度和组件的发布粒度一致。一个组件中的类要么都可以重用，要么都不是可重用的。

👉共同闭包原则：如果一个应用中的代码需要同时、为统一目的发生修改，尽量让这种修改都集中在一个组件中，而不是分散在多个组件中。

👉共同复用原则：经常共同复用的类和模块放在同一个组件中，不紧密相连的类不应该放在同一个组件中。

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

👉稳定依赖原则：依赖关系必须指向更稳定的方向

👉稳定抽象原则：一个组件的抽象化程度应该与其稳定性保持一致



做作业也是学习的过程，了解到好多概念和设计理念，需要不断地消化、实践。