todo
0 开篇
中台本质是业务模型,微服务是业务模型的系统落地,DDD 是一种设计思想,它可以同时指导中台业务建模和微服务设计,它们之间就是这样的一个铁三角关系。DDD 强调领域模型和微服务设计的一体性,先有领域模型然后才有微服务,而不是脱离领域模型来谈微服务设计。
1 微服务 DDD
2 领域、子域、核心域、通用域和支撑域
DDD 的领域就是这个边界内要解 决的业务问题域。
我们把划分出来的多个子领域称为子域,每个子域对应一个更小的问题域或更小的业务范围。
领域的核心思想就是将问题域逐级细分,来降低业务理解和系统实现的复杂度。通过领域细
分,逐步缩小微服务需要解决的问题域,构建合适的领域模型,而领域模型映射成系统就是
微服务了。
核心域、支撑域和通用域的主要目标是:通过领域划分,区分不同子域在公司内的不同功能
属性和重要性,从而公司可对不同子域采取不同的资源投入和建设策略,其关注度也会不一
样。
3 界定上下文
在事件风暴过程中,通过团队交流达成共识的,能够简单、清晰、准确描述业务涵义和规则的语言就是通用语言
DDD 在战略设计上提出了“限界上下文”这个 概念,用来确定语义所在的领域边界。
通用语言:团队内部能够清晰、准确的描述业务模型的语言就是通用语言。 限界上下文:为通用语言划定边界,并提供语义上下文。领域内所有界限上下文的模型构 成了整个领域模型。 理论上,某些条件下,限界上下文的划分也最终确定了微服务的边界。
4 实体和值对象
实体有唯一ID,实体是通过ID来区分不同实体的,值对象是通过属性来区分不同值对象的,即时实体的属性都发生了改变,只要它的ID还是原来的ID,实体还是那个实体。值对象只要改变了属性值,就已经不是原来的值对象了。
在领域建模时,我们可以将部分对象设计为值对象,保留对象的业务涵义,同时又减少了实体的数量;在数据建模时,我们可以将值对象嵌入实体,减少实体表的数量,简化数据库设计。
5 聚合和聚合根
领域模型内的实体和值对象就好比个体,而能让实体和值对象协同工作的组织就是聚合,它用来确保这些领域对象在实现共同的业务逻辑时,能保证数据的一致性。
你可以这么理解,聚合就是由业务和逻辑紧密关联的实体和值对象组合而成的,聚合是数据修改和持久化的基本单元,每一个聚合对应一个仓储,实现数据的持久化
判断一个实体 是否是聚合根,你可以结合以下场景分析:是否有独立的生命周期?是否有全局唯一 ID? 是否可以创建或修改其它对象?是否有专门的模块来管这个实体。
总结:
聚合的特点:高内聚、低耦合,它是领域模型中最底层的边界,可以作为拆分微服务的最小 单位,但我不建议你对微服务过度拆分。但在对性能有极致要求的场景中,聚合可以独立作 为一个微服务,以满足版本的高频发布和极致的弹性伸缩能力。
一个微服务可以包含多个聚合,聚合之间的边界是微服务内天然的逻辑边界。有了这个逻辑
边界,在微服务架构演进时就可以以聚合为单位进行拆分和组合了,微服务的架构演进也就
不再是一件难事了。
聚合根的特点:聚合根是实体,有实体的特点,具有全局唯一标识,有独立的生命周期。一 个聚合只有一个聚合根,聚合根在聚合内对实体和值对象采用直接对象引用的方式进行组织 和协调,聚合根与聚合根之间通过 ID 关联的方式实现聚合之间的协同。
实体的特点:有 ID 标识,通过 ID 判断相等性,ID 在聚合内唯一即可。状态可变,它依附 于聚合根,其生命周期由聚合根管理。实体一般会持久化,但与数据库持久化对象不一定是 一对一的关系。实体可以引用聚合内的聚合根、实体和值对象。
值对象的特点:无 ID,不可变,无生命周期,用完即扔。值对象之间通过属性值判断相等 性。它的核心本质是值,是一组概念完整的属性组成的集合,用于描述实体的状态和特征。 值对象尽量只引用值对象。
产生聚合的过程一般是,事件风暴->领域对象 ->实体、值对象->聚合根->聚合
6 领域事件:解耦微服务的关键
7 DDD分层架构:有效降低层与层之间的依赖
1.用户接口层
用户接口层负责向用户显示信息和解释用户指令。这里的用户可能是:用户、程序、自动化测试和批处理脚本等等。
2.应用层
协调多个聚合的服务和领域对象完成服务编排和组合,协作完成业务操作。
3.领域层
领域层包含聚合根、实体、值对象、领域服务等领域模型中的领域对象。
首先,领域模型的业务逻辑主要是由实体和领域服务来实现的,其中实体会采用充血模型来
实现所有与之相关的业务功能。其次,你要知道,实体和领域对象在实现业务逻辑上不是同
级的,当领域中的某些功能,单一实体(或者值对象)不能实现时,领域服务就会出马,它
可以组合聚合内的多个实体(或者值对象),实现复杂的业务逻辑。
4.基础层
基础层是贯穿所有层的,它的作用就是为其它各层提供通用的技术和基础服务,包括第三方
工具、驱动、消息中间件、网关、文件、缓存以及数据库等。比较常见的功能还是提供数据
库持久化。
8
思路基本是一致的,都是以领域模型为中心,加上用于编排的应用层逻辑
领域层实现面向领域模型,实现领域模型的核心业务逻辑,属于原子模型,它需要保持领域模型和业务逻辑的稳定,对外提供稳定的细粒度的领域服务,所以它处于架构的核心位置。
应用层实现面向用户操作相关的用例和流程,对外提供粗粒度的API服务。它就像一个齿轮一样进行前台应用和领域层的适配,接收前台需求,随时做出响应和调整,尽量避免将前台需求传导到领域层。应用层作为配速齿轮则位于前台应用和领域层之间。
软件开发中遇到的所有问题,都可以通过增加一层抽象来解决。
面向用户的展现层可以快速响应外部需求进行调整和发布,灵活多变,
应用层通过服务组合和编排实现业务流程的快速适配上线,
领域层基本就不需要太多的变化了,
如果真的万不得已要修改领域层,领域层也要遵循面向对象的6大原则(单一职则原则、开闭原则、里氏替换原则、依赖倒置原则、接口隔离原则、迪米特原则),保证领域层高内聚低耦合。
中台本质上是领域的子域,它可能是核心域,也可能是通用域或支撑域。通常大家认为阿里的中台对应DDD的通用域,将通用的公共能力沉淀为中台,对外提供通用共享服务。
9、中台
中台是企业级能力复用平台
10 DDD、中台和微服务:它们是如何协作的?
中台是抽象出来的业务模型,微服务是业务模型的系统实现,DDD作为方法论可以同时指导中台业务建模和微服务建设,三者相辅相成,完美结合。
DDD:
战略设计和战术设计
11 DDD实践:如何用DDD重构中台业务模型?
自顶向下的策略适用于全新的应用系统建设,或旧系统推倒重建的情况。
自底向上策略适用于遗留系统业务模型的演进式重构。
12 领域建模:如何用事件风暴构建领域模型
DDD: 事件风暴--产品愿景--场景分析--领域建模--微服务拆分与设计。
传统: 产品需求--需求分析--详细设计--ER模型--UML设计
貌似最后都能产生模型图,一个叫领域模型,一个叫ER图,是不是关键就在这里,一个是面向业务领域建模,一个是面向底层数据层设计,也是DDD和传统的分水岭
13 14 代码模型
第一点:聚合之间的代码边界一定要清晰。聚合之间的服务调用和数据关联应该是尽可能的松耦合和低关联,聚合之间的服务调用应该通过上层的应用层组合实现调用,原则上不允许聚合之间直接调用领域服务。这种松耦合的代码关联,在以后业务发展和需求变更时,可以很方便地实现业务功能和聚合代码的重组,在微服务架构演进中将会起到非常重要的作用。
第二点:你一定要有代码分层的概念。写代码时一定要搞清楚代码的职责,将它放在职责对应的代码目录内。应用层代码主要完成服务组合和编排,以及聚合之间的协作,它是很薄的一层,不应该有核心领域逻辑代码。领域层是业务的核心,领域模型的核心逻辑代码一定要在领域层实现。如果将核心领域逻辑代码放到应用层,你的基于DDD分层架构模型的微服务慢慢就会演变成传统的三层架构模型了。
15 逻辑边界、物理边界和代码边界:
微服务架构式演进 :
Martin Fowler 在提出微服务时,他提到了微服务的一个重要特征——演进式架构。那什么是演进式架构呢?演进式架构就是以支持增量的、非破坏的变更作为第一原则,同时支持在应用程序结构层面的多维度变化。
错误的方式: 大单体应用 小单体应用
微服务的边界: 逻辑边界、物理边界和代码边界
16 视图:如何实现服务和数据在微服务各层的协作?
17 从后端到前端:微服务后,前端如何设计
18 实例
19、微服务设计和拆分要坚持哪些原则?
微服务设计原则
微服务设计原则中,如高内聚低耦合、复用、单一职责等这些常见的设计原则在此就不赘述了,我主要强调下面这几条:
第一条:要领域驱动设计,而不是数据驱动设计,也不是界面驱动设计。
第二条:要边界清晰的微服务,而不是泥球小单体。
第三条:要职能清晰的分层,而不是什么都放的大箩筐。
第四条:要做自己能hold住的微服务,而不是过度拆分的微服务。
微服务拆分需要考虑哪些因素?
理论上一个限界上下文内的领域模型可以被设计为微服务,但是由于领域建模主要从业务视角出发,没有考虑非业务因素,比如需求变更频率、高性能、安全、团队以及技术异构等因素,而这些非业务因素对于领域模型的系统落地也会起到决定性作用,因此在微服务拆分时我们需要重点考虑它们。我列出了以下主要因素供你参考。
1. 基于领域模型
2. 基于业务需求变化频率
3. 基于应用性能
4. 基于组织架构和团队规模
5. 基于安全边界
6. 基于技术异构等因素
分布式架构关键设计10问
1选择什么样的分布式数据库?
2如何设计数据库分库主键?
3数据库的数据同步和复制
4跨库关联查询如何处理?
5如何处理高频热点数据?
6前后序业务数据的处理
7数据中台与企业级数据集成
8BFF与企业级业务编排和协同
9分布式事务还是事件驱动机制?
10多中心多活的设计
ref