DDD 作业

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





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



微服务架构是用来解决业务复杂导致单体服务过于庞大、业务耦合高、代码分支管理困难、部署困难、性能瓶颈等问题。

微服务的基本思想在于考虑围绕着业务领域组件来创建应用，这些应用可独立地进行开发、管理和加速。在分散的组件中使用微服务云架构和平台，使部署、管理和服务功能交付变得更加简单。

微服务是利用组织的服务投资组合，然后基于业务领域功能分解它们，在看到服务投资组合之前，它还是一个业务领域。

个人理解：从其他架构师课程的学习，以前认为，微服务就是为了追寻高并发、可伸缩、高性能的目标。所以脱离业务谈架构都是耍流氓，所有架构演进都是为了解决业务问题而诞生的。复杂的微服务架构也仅仅是利用分布式技术模拟单机pc系统，去完成单机不能完成的任务。



领域驱动设计是指导微服务架构的业务拆分的方法论，从业务的边界考虑，将整体业务拆分不同的子域，将子域抽象为微服务的子服务，从业务角度使服务降低耦合性；

个人理解：应该是单一职责原则的延伸。一个广义上的职责就是域，细分的就是子域，职责的边界就是限界上下文

职责单一是为了更好的交互，而交互部分成为上下文映射

这四个部分就是DDD战略设计的主要内容：确定职责以及交互



中台架构是微服务及领域驱动的应用，中台实际就是子域服务；

中台是支持多个前台业务且具备业务属性的共性能力组织。

有点三点含义：

1. 中台必须具备业务属性。

2. 中台是一种共性能力组织，支持了多个业务。

3. 中台支持的是多个前台业务。

业界常说的中台，包括业务中台，数据中台、用户中台、搜索中台、推荐中台、技术中台、组织中台等

个人：只听过猪的名字，连🐷怎么跑的都没见过，所以没啥理解



组件设计原则是微服务思想在代码层面上的微观表现，依赖倒置、单一职责等原则都能反映到微服务架构设计原则中。

组件设计是软件设计开发最精髓所在，凝聚了数据结构、面向对象、设计模式、线程并发同步、操作系统等诸多领域的最核心技术，一直是设计开发领域彰显技术水准的最高领地。一个组件，要想被广泛重用，满足不同系统的使用要求，就要求组件有足够的能力适应不同的应用场合，提供满足需要的功能，并表现出优秀的性能。

个人理解：这一段时间正在做微服务的组件化，之前几乎是用单体的思路来做的。用什么直接依赖什么，所以往往是一个微服务发生了变化，导致所有微服务都要进行升级改代码。我在对这个做重构的时候，就是应用了

DDD战略设计：

划分职责，无关的依赖都剔除

组件落地

必需的依赖的使用接口

共同复用，不依赖不需要的东西

解决循环依赖

多组件聚合的放到应用方，这里学到其实应用方本身也是一个组件，本身就是一个上下文映射。

基本组件保持稳定--

耦合组件依赖基本组件