DDD领域驱动设计
2023-11-08 15:24:51 2 举报AI智能生成
DDD领域驱动设计
作者其他创作
大纲/内容
DDD概述
DDD本质：以客户和产品为导向，对业务进行分而治之
DDD适用范围：产品导向、中大规模系统、API经济、中台化、业务持续可迭代
DD不适用范围：中小规模系统（本身业务体量小，功能单一，选择mvc架构是最好的）、项目化交付的系统（研发周期短，按照甲方的需求定制功能）
DDD 的核心思想：是通过领域驱动设计方法定义领域模型，从而确定业务和应用边界，保证业务模型与代码模型的一致性
DDD与面向对象
面向对象
面向对象分析与设计（OOAD）
面向对象编程（OOP）
联系
OOAD与DDD都是建模和设计的思想
部分建模方法和工具可以通用
区别
OOAD没有战略设计；DDD通过战略设计划分领域和模型
OOAD仅用对象和联系描述世界；DDD描述更细致
DDD与敏捷开发
敏捷关注流程和文化；DD关注建模和设计
敏捷重人员轻文档；DDD重文档（文档是统一语言建立的前提）
DDD知识体系
分支主题
领域（domain）
本质：问题域
界限在指定的业务需求中
有清晰的范围边界
子域（sub-domain）
核心域
决定产品核心竞争力的子域，最高的优先级，研发投入的重点
支撑域
实现核心域目标所需的，但重要程度不如核心域的子域，一般具备强烈的个性化需求
通用域
具有通用功能，可被多个子域使用的的是通用域
该子域所解决的问题一般是业界常见问题，有成熟的解决方案，可直接购买或简单修改来使用
限界上下文（bounded context）
限界上下文含义：一种语义上的上下文边界，在这个边界内，模型组件又特定的含义且做特定的事情，且语义明确无歧义
限界上下文作用：定义领域边界，确保在特定边界内，每个领域对象具有唯一的含义，在这个边界内组合这些对象并构建领域模型
限界上下文是团队分工的单位
与微服务关系：微服务是限界上下文的实现方式
命名规则：领域名+上下文
上下文映射
上下文映射含义：描述团队之间协作关系鸡上下文之间的集成关系；一个上下文是否依赖另一个上下文，被依赖的上下文如何提供服务
上游：被依赖方
下游：依赖方
上下文映射模式
客户-供应商开发（Customer-Supplier Development）
上下文之间有组织的上下游依赖。
开放主机服务（OHS）
上游为所有下游提供一套公共API
一般指上游
防腐层（ACL）
把上游模型转化成下游模型
引入防腐层的情况
把外部上下文模型转化成下游模型（可防止被外部大泥球污染内部上下文）
不同上下文之间的团队协作关系，如果是供奉者关系，建议引入防腐层，避免外部上下文变化对本上下文的侵蚀。
该访问本上下文使用广泛，为了避免改动影响范围过大
本质：将外部上下文的交互行为封装到防腐层中
合伙人（Partnership）
两个上下文紧密合作的关系，一荣俱荣，一损俱损。
共享内核（Shared Kernel）
两个上下文依赖部分共享的模型。
顺从者（Conformist）
无模型间转换，直接沿用部分模型
一般指下游
分道扬镳（SeparateWay）
两个完全没有任何联系的上下文。
大泥球（Big Ball of Mud）
混杂在一起的上下文关系，需要避免
通用语言（Ubiquitous Language）
通用语言概述
团队内部统一使用的语言规则
用于精准定义与讨论模型
最终要体现在代码里
通用语言构成
类和操作的名称
施加于模型之上的规则和约束
应用于领域模型的模式
实体（Entity）
业务形态
在战略设计时，实体是领域模型的一个业务对象，集多个业务属性、业务操作或行为于一体。
在业务场景分析时，可以根据命令、操作或者领域事件，找出产生这些业务行为的实体对象，将依存度高和业务关联紧密的多个实体和值对象进行聚类，形成聚合
代码形态
在代码模型中，实体的表现形式是实体类，这个类包含了实体的属性和方法，通过这些方法实现实体自身的业务行为和业务逻辑。
这些实体类通常采用充血模型，与实体相关的所有业务逻辑都在实体类方法中实现，跨多个实体的领域逻辑则在领域服务中实现。
运行形态
实体以领域对象（DO）的形式存在，每个实体对象都有唯一的ID。
可以对一个实体对象进行多次修改，修改后的实体数据和原来的数据可能会大不相同。但依然是同一个实体。
数据库形态
与传统数据模型设计优先不同，DDD是先构建领域模型，通过场景分析找出实体对象和行为，再将实体对象映射到数据持久化对象。
在领域模型映射到数据模型时，一个实体可能对应0个、1个或者多个数据库持久化对象。
大多数情况下实体与持久化对象是一对一。
值对象（Value Object）
值对象是领域模型中的一个基础对象，它跟实体一样都来源于事件风暴所构建的领域模型，都包含了若干个属性，它与实体一起构成聚合。
业务形态
值对象是若干个属性的集合，只有数据初始化操作和有限的不涉及修改数据的行为，基本不包含业务逻辑
代码形态
如果值对象是单一属性，则直接定义为实体类的属性
如果值对象是属性集合，则将它设计为值对象类，这个类将具有整体概念的多个属性归集到属性集合，这样的值对象没有ID，会被实体整体引用
数据库形态
属性嵌入：降低范式，增加冗余字段
序列化大对象：作为属性字段，但以JSON形式保存对象
聚合（Aggregate）
聚合是领域对象的显式分组，旨在支持领域模型的行为和不变性，同时充当一致性和事务性边界
聚合是由业务和逻辑紧密关联的实体和值对象组合而成
聚合内数据的修改必须由聚合根统一组织，以确保每次数据修改都是按照聚合内统一的业务规则来完成，聚合是数据修改和持久化的基本单元
每一个聚合设计一个仓储完成聚合数据的持久化操作。为了避免聚合数据频繁地提交，将聚合内变更的数据封装在一次交易中提交仓储完成持久化
聚合的设计过程
步骤一：采用事件风暴，梳理业务场景中所有业务行为，找出产生这些行为的所有实体和值对象
步骤二：从众多实体中找出适合作为聚合对象管理者的聚合根
步骤三：找出与聚合根关联的所有紧密依赖的实体和值对象，构建出一个包含聚合根、多个实体和值对象的领域对象的聚合
步骤四：在聚合内根据聚合根、实体和值对象的依赖关系，找出它们的引用和依赖关系
步骤五：多个聚合根据业务语义和上下文边界，划分到同一个限界上下文内，完成领域建模
聚合的设计原则
1.在一致性边界内建模真正的不变条件
聚合是用来封装真正的业务不变性，而不是简单地将对象组合在一起。
聚合内有一套不变的业务规则，各实体和值对象按照统一的业务规则运行，保证聚合内对象数据的一致性。
2.设计小聚合
小聚合设计可以降低由于业务过大，在业务变化时导致聚合重构的可能性。这样领域模型就更能适应业务的变化。
3.通过唯一标识引用其他聚合
聚合之间是通过引用聚合根ID的方式，而不是通过直接对象引用的方式
4.在边界之外使用最终一致性
在聚合内采用数据强一致性，在聚合之间采用数据最终一致性
一次事务中，最多只能修改一个聚合的数据
如果一次业务交易操作涉及了多个聚合数据的修改，那么应采用领域事件驱动机制，通过数据最终一致性异步更新所有聚合的数据
5.通过应用层实现跨聚合的服务调用
聚合的设计模式
仓储模式（Repository Mode）
工厂模式（Factory Mode）
聚合根（Aggregate Root）
聚合的根实体，一个聚合里只有一个聚合根
聚合根是为了避免由于复杂数据模型缺少统一的业务规则控制，从而导致聚合、实体之间数据不一致性的问题。
外部对象不能直接访问聚合内实体，需要先访问聚合根，再导航到聚合内部实体。
特点：聚合根是聚合的管理者，对内其协调实体和值对象完成业务逻辑。对外则提供通过聚合ID供其他聚合关联引用，屏蔽外部对内部实体的直接访问和修改
仓储（Repository）
主要完成聚合内的领域对象持久化
隔离业务实现逻辑与基础层资源实现逻辑，降低它们之间的耦合和相互影响
介于领域层和基础层（接口放在领域层，实现放在基础层）
仓储接口
面向领域层提供基础层数据处理相关的访问接口
仓储实现
完成仓储接口对应的数据持久化相关的逻辑处理
JPA更接近DDD的设计思想。它采用充血模型，有聚合根的设计思想，但美中不足是性能不可控。而Mybatis虽然性能可控，但它却采用了贫血模型。
一个聚合只能有一个仓储，聚合与仓储是一对一关系
工厂（Factory）
主要用于聚合内领域对象的创建和数据初始化
对于聚合来说，应该一次性创建整个聚合，并且确保不变条件得到满足
工厂只承担创建模型的工作，不具有其它领域行为
方式：工厂类、工厂方法等
领域事件（Domain Event）
领域事件用来表示领域中发生的事件。一个领域事件将导致进一步的业务操作。
命名方法：名词+动词完成时
领域事件一般都会结合消息中间件和事件发布订阅的异步处理方式，实现数据最终一致性。
事件驱动架构（EDA）
切断领域模型之间的强依赖关系，事件发布后，发布方不关心订阅方事件处理是否成功，可以实现领域模型的解耦，维护领域模型的独立性和数据的一致性
微服务之间的数据不必要求强一致性，而是基于事件的最终一致性
领域事件驱动实现机制
事件构建和发布
领域事件基类（DomainEvent）
id：标识（全局唯一）
timestamp：时间戳
source：来源
data：传输数据
DomainEvent()
getId()
getTimestamp()
getSource()
getData()
事件数据持久化（以便后续查账及数据恢复）
事件总线
消息中间件
源端发布者
发布消息
事件数据持久化
消息补偿
目的端订阅者
订阅消息
业务处理
事件接受和处理
领域服务（Domain Service）
当一些业务逻辑不属于某个实体时，可以把这些逻辑单独拿出来放到领域服务中
跨多个实体的业务逻辑通过领域服务来实现
均为无状态的操作
领域服务典型场景
执行一个显著的业务操作
对领域对象进行转换
以多个领域对象作为输入参数进行计算，结果产生一个值对象
应用服务（Application Service）
跨多个聚合的业务逻辑通过应用服务来实现
应用服务里不要处理业务逻辑，只在领域服务里处理业务逻辑
应用服务是领域服务的客户方，应用服会调用领域服务里的方法
通常的可以放在应用服务中的逻辑有：参数验证、错误处理、监控日志、事务处理、认证与授权
分层架构
分层架构概述
依赖原则
每层只能与位于其下方的层发生耦合
松散分层架构
允许某层与其任意下方的层发生依赖
如传统四层架构
严格分层架构
任何层只能对位于其直接下方的层产生依赖
如：新四层结构
推荐适用严格分层架构
架构演进
MVC三层架构 vs DDD四层架构
分支主题
四层架构（传统） vs 四层架构（DIP）
传统：松散分层架构，其他三层均依赖基础层
DIP：严格分层架构，其他三层不再依赖基础层
分支主题
DDD四层架构
接口层（Interfaces）
facade（接口服务）
封装应用服务，适配不同前端应用的集成技术体系，提供不同类型的服务接口适配
assembler（数据组装器）
完成前端DTO和后端DO对象的组装和转换等操作，按需提供数据适配的工具类
作用
面向前端用户提供接口和数据适配相关的功能
避免暴露微服务的核心业务逻辑
避免因为前端不同的数据展示需求，而在后端定制开发不同的应用服务或领域服务来适配
应用层（Application）
协调领域层多个聚合完成服务的组合和编排
适应业务流程快速变化的需求
领域层（Domain）
实现领域模型的核心业务逻辑，体现领域模型的业务能力
主要关注实现领域对象或者聚合自身的原子业务逻辑，不太关注外部用户操作或者流程等方面的业务逻辑
基础层（Infrastructure）
贯穿了DDD所有层，为其他各层提供通用的技术和基础服务
实现领域层定义的repository相关接口，实现对聚合根的查询保存（即返回给领域层的是Entiry，而非PO或BO数据）
对应用层提供DAO接口，返回PO或BO数据
DDD建模设计流程
模型：对领域的抽象和模拟
建模：对特定领域问题建立模型
设计：将领域模型落地成代码
阶段一：业务场景分析
方法一：事件风暴
可以理解为头脑风暴，领域专家会和设计、开发人员一起建立领域模型
方法二：领域故事分析
场景识别（用户故事）与层级划分
阶段二：建立通用语言
阶段三：战略设计
战略设计概述
从业务视角出发，对领域进行细分，划分出业务上下文边界，然后建立领域模型
上下文边界和领域模型可以作为微服务拆分和设计的输入，指导微服务落地时的拆分和设计
是DDD与传统建模设计方法的核心区别之一
目的：分解模型以便控制复杂性
本质：对问题空间和解决方案空间进行分解
步骤一：领域划分
领域划分含义：以分离关注点为原则，对问题空间进行划分
领域划分的核心思想就是将问题域逐级细分，采用分而治之的策略，将复杂问题简单化，从而降低业务理解和系统实现的复杂度
精炼：领域划分的方法，重点是区分核心域和其他域
步骤二：寻找限界上下文
步骤三：确定上下文映射
步骤四：提炼领域模型
阶段四：战术设计
从技术视角出发，侧重于领域模型技术实现，完成软件开发落地，包括：聚合根、实体、值对象、领域服务、应用服务、资源库等代码逻辑设计和实现
将领域模型中的领域对象与代码模型中的代码对象建立映射关系，将业务架构和系统架构进行映射和绑定
四个阶段按顺序开展，但后一阶段的开始并不会导致前一阶段的结束，即随着项目开展，四个阶段会同步开展并相互影响
DDD微服务工程结构
Module
模块是DDD中明确提到的一种控制限界上下文的手段，在工程中，一般尽量用一个模块来表示一个领域
一般的工程中包的组织方式为{com.公司名.组织架构.业务.上下文.*}，这样的组织结构能够明确的将一个上下文限定在包的内部
interfaces（接口层）
主要存放数据的组装、数据传输格式转换以及facade接口封装等代码
前端应用通过这一层的接口，从应用服务获取前端展现所需的数据。
处理前端用户发送的REStful请求， 解析用户输入的配置文件，并将数据传递给application层
facade（接口服务）
封装应用服务，提供较粗粒度的调用接口，或者将用户请求委派给一个或多个应用服务进行处理
dto（数据传输对象）
前端应用数据传输的载体，不实现任何业务逻辑
assembler（数据组装器）
实现DTO与DO领域对象之间的相互转换和数据交换
application（应用层）
主要存放应用服务和事件等代码
向下完成领域服务间的组合和编排
向上为接口层提供各种应用数据支持服务
event（事件）
主要存放事件相关的代码
publish（发布）
主要存放事件发布相关代码
subscribe（订阅）
主要存放事件订阅相关代码
service（应用服务）
应用服务会对多个领域服务或其他微服务的应用服务进行封装、编排和组合，对外提供粗粒度的服务
根据需要增加assembler和dto代码目录结构
domain（领域层）
主要存放聚合根以及实体、方法、值对象、领域服务和事件等相关代码
通过多个聚合代码包，实现领域模型的核心业务逻辑
aggregate（聚合）
多个，命名根据业务定义
entity（实体）
存放聚合根、实体和值对象等相关代码
event（事件）
存放事件实体、事件活动相关的业务逻辑代码
service（领域服务）
存放领域服务、工厂服务等相关代码
repository（仓储）
存放仓储服务相关的代码
infrastructure（基础层）
主要存放为其他各层提供的通用技术能力、三方软件包、数据库服务、配置和基础资源服务的代码
config（配置）
主要存放配置相关代码。
util（工具）
主要存放平台、开发框架、消息、数据库、缓存、文件、 总线、网关、第三方类库和通用算法等基础代码
api、driver、eventbus、mq等
DDD其他知识
领域模型分类
失血模型
领域层仅仅包含数据的定义和getter/setter方法，业务逻辑和应用逻辑都放到服务层中
贫血模型
领域层包含了一些业务逻辑，但不包含依赖持久层的业务逻辑。这部分依赖于持久层的业务逻辑将会放到服务层中
MVC普遍采用贫血模型
充血模型
领域层包含了所有的业务逻辑，包括依赖于持久层的业务逻辑。所以，使用
DDD推荐使用充血模型
胀血模型
把和业务逻辑不相关的其他应用逻辑（如授权、事务等）都放到领域层中。
对象命名规范
视图对象
所处层：接口层（适配层）
用于封装展示层指定页面或组件 的数据
命名
业内常用命名：VO（View Object）
阿里规范：VO（View Object）
推荐：VO（View Object）
数据传输对象
所处层：应用层
用于前端应用与微服务应用层或者微服务之间的数据组装和传输，是应用之间数据传输的载体
命名
业内常用命名：DTO（Data Transfer Object）
阿里规范：DTO（Data Transfer Object）
推荐：DTO（Data Transfer Object）
数据存储对象
所处层：基础层
与数据库结构一一映 射，它是数据持久化过程中的数据载体
命名
业内常用命名：PO（Persistent Object）
阿里规范：DO（Data Object）
推荐：DO（Data Object）
领域对象
所处层：领域层
微服务运行时核心业务对象 的载体，DO一般包括实体或值对象
命名
业内常用命名：DO（Domain Object）
阿里规范：BO（Business Object）
推荐：根据领域通用语言命名
数据流转规范
在领域的开放服务，通过信息传输对象（DTO）来完成与外界的数据交互
在领域内部，通过领域对象（DO）作为领域内部的数据和行为载体
在仓储内部，通过数据库持久化对象（PO）进行数据库资源的交互
DTO与DO的转换发生在领域服务内，DO与PO的转换发生在资源库内
微服务架构模型
洋葱架构模型
分支主题
六边形架构模型
分支主题
分支主题
与DDD关系：核心设计思想一致
建模设计方法
CBM（组件化业务模型）
SOA（面向服务架构模型）
UML（用例分析法）
Domian Storytelling（领域故事陈述法）
用户故事
定义：对系统特性的非正式的自然语言描述，描述【谁】需要【什么】以及【为什么】需要
本质：描述问题细节（问题空间）
用户故事三要素（3C）
卡片（Card）
谈话（Conversation）
验证（Confirmation）
挖掘用户故事
1.简单描述用户需求
2.围绕简单描述进行讨论（把握粒度，不要太细节）
3.明确如何验证
Event Storming（事件风暴法）
概述：事件风暴是一种以协作探索复杂业务领域为目标的，灵活的工作坊（workshop）形式的活动
事件风暴相关概念
事件（Event）
事件即事实，即在业务领域中那些已经发生的事件就是事实，并可能需要保存下来或者让“别人”响应
如：【用户已注册】，【激活邮件已发送】等
注：一般查询操作不会触发事件的产生，所以查询操作不是事件，如点击了查询按钮显示了数据列表，不会有【数据已查询】这样的事件
决策命令（Command）
决策命令产生了事件，可理解为产生事件的动作，与事件一一对应
如【用户已注册】事件对应的决策命令就是【注册用户】。在实践中只需要将事件“反过来”就行了
发起命令的参与者（User/Actor）
前面的决策命令一定是由某个人（系统）来发起的
如：【注册用户】这个命令，是由【普通用户】这个Actor发起的
读模型（Read Model）
某个Actor做出决策命令Command的前提是需要看到某些信息，或者说，支撑Actor更容易做出决策命令Command的信息
读模型一般是通过Web页面（UI/UX）来展示更多的信息，以让用户更容易做出决策
聚合（Aggregate）
某个Actor在某个聚合调用某种Command产生了某个Event
如：【用户已注册】事件，是由【普通用户】在【注册薄】上调用【注册用户】这个命令而产生
外部系统（External System）
Event也可能是由外部系统或者某种规则自动触发Command而产生
事件风暴流程
1.通过事件流探索业务全景
1..产品经理写出第一个比较重要的事件
2.团队围绕着这个事件，一起分析这个事件的前置事件以及后置事件
注意
事件不需要严格按照先后顺序排列，将想到的所有事件先写出来
注意控制讨论始终Fouces在事件上，不关注此事件怎么产生的
产出：【事件】集合
2.逐个思考每个事件是怎么产生的
1.思考导致事件结果的命令
2.思考发出命令的参与者
产出：【参与者】集合、【外部系统】集合
注意
此过程需要重新整理和补充遗漏事件
此过程需要关注事件的先后关系，以及事件与规则之间的关系
3.添加读模型和UI
1.以用户决策的角度来思考，用户需要什么样的信息展示在UI上才能做出决策命令
产出：【读模型】集合
4.添加聚合
1.从第一个事件从头开始，写出所有聚合
2.以聚合为核心，将关系紧密的聚合以及相关事件等内容移动到一起
产出：【聚合】集合
5.划分子域，识别核心域、支撑域与通用域
事件风暴适用范围
不适合多于6个人以上的团队，人太多参与感会降低，效果会下降很多。如果是大型项目，需要将项目进行拆分，以让负责子功能的小团队单独做事件风暴
事件风暴较适合一线业务部门，或者说业务系统，如果是纯技术的，如技术中间件，注册中心等这些服务，则不太适合采用事件风暴
4C（四色建模法）
事件（Moment-Interval）
角色在某段事件内发生的事件明细
使用聚合根或实体描述
事物（Party、Place、Thing）
人、部门、地点、物品等
使用聚合根或实体描述
角色（Role）
对PPT按业务场景细分的角色
使用实体或值对象描述
描述（Description）
对PPT的分类描述
使用值对象描述
CQRS
CQS （命令查询分离）
Command
改变对象的内部状态，但不返回任何内容
Query
返回信息内容，但不改变对象内部状态
CQRS（Command Query Responsibility Segregation）
Command API（命令路由）
专用于更改应用程序状态
使用POST实现
Query API（查询路由）
专用于返回有关应用程序状态信息
使用GET实现
Event API（事件路由）
基于事件溯源（Event Sourcing）模式
中台
阿里中台战略
传统企业大平台战略
概述：将通用的公共能力独立为共享平台，通过API或数据服务的形式对外提供服务
目的：解决系统重复建设的问题
局限
没有与企业内其他平台或应用实现从前端到后端的页面、业务流程和数据的全面融合
没有将企业核心业务服务链路作为企业级解决方案来考虑
阿里中台战略
概述：中台是一个基础的理念和架构，用中台的思想建设、联通所有基础服务，共同支持上端的业务。
大中台、小前台
双中台先行：业务中台、数据中台
其他中台跟进：移动中台、技术中台、研发中台等
业务中台更多的是支持在线业务，数据中台则提供基础数据处理能力和很多的数据产品供所有业务方使用
前台、中台、后台
前台
主要面向客户以及终端销售者，实现营销推广以及交易转换
中台
主要面向运营人员，完成运营支撑。
业务中台
业务中台建设类型
通用能力中台
通用能力中台更强调标准化和抽象能力，面向企业所有业务领域实现能力复用。
核心能力中台
快速适应不同业务场景和渠道的企业核心能力
业务中台建设目标
解决业务能力重复建设和复用的问题，实现企业级业务能力的复用
数据中台
数据中台建设目标
1.完成企业全域数据的采集与存储，实现不同业务类别中台数据的集中管理。
2.按照标准的数据规范与模型，基于不同主题域或场景对数据进行加工和处理，形成面向不同主题和场景的数据应用
3.建立数据驱动的运营体系，基于各个维度的数据，萃取数据价值，组合企业各种能力，支持业务智能化和商业模式的创新，实现精细的数字化运
数据中台建设步骤
步骤一：实现各中台业务数据的汇集，解决数据孤岛和初级数据共享问题
步骤二：实现企业级实时或非实时全维度数据的深度融合、加工和共享
步骤三：萃取数据价值，支持业务创新，加速从数据转换为业务价值的过程
后台
台主要面向后台管理人员，实现流程审核、内部管理以及后勤支撑
中台的三个关键能力
1.对前台业务的快速响应能力。
2.企业级的复用能力。
3.从前台、中台到后台的设计、研发、页面操作、流程、服务和数据的无缝联通、融合能力。
中台能力框架
企业级综合能力
业务能力
主要体现为对中台领域模型的构建能力，对领域模型的持续演进能力，企业级业务能力的复用、融合和产品化运营能力，以及快速响应市场的商业模式创新能力
数据能力
主要体现为企业级的数据融合能力、数据服务能力以及对商业模式创新和企业数字化运营的支撑能力
技术能力
主要体现为对设备、网络等基础资源的自动化运维和管理能力，对微服务等分布式技术架构体系化的设计、开发和架构演进能力。
组织能力
主要体现为一体化的研发运营能力和敏捷的中台产品化运营能力，为快速建设自适应的组织架构和中台建设方法体系等方面的能力
业务中台
业务中台承载了企业核心关键业务，是企业的核心业务能力，也是企业数字化转型的重点
业务中台提供服务的方式
API接口级服务
页面级服务
数据中台
数据中台主要构成
数据采集
数据集成
数据治理
数据应用
数据资产管理
数据标准
指标建设
数据仓库
大数据
技术中台
技术中台主要构成
API网关
服务路由
服务鉴权
流量控制
访问日志
开发框架
前端开发框架
微服务开发框架
微服务治理组件
注册发现
熔断限流
负载均衡
配置管理
链路追踪
数据处理组件
缓存
消息中间件
数据复制
应用日志
搜索引擎
分布式事务
分布式数据库
OLTP
OLAP
HTAP
研发运营
研发运营一体化（DevOps）
组织协同+流程优化+工具平台
全链路监控
云平台
云服务
IaaS
PaaS
云运营
租户管理、服务目录管理、流程管理和计量计费等
云运维
服务水平管理、容量管理、权限管理、日志管理、监控告警和报表分析等。
DDD、中台、微服务
中台本质上是企业的业务模型，而微服务则是中台领域模型系统落地时的一种架构实现方式
业务中台建模：DDD战略设计
业务中台落地：DDD战术设计+微服务
DDD本质
在研究和解决业务问题时，DDD会按照一定的规则将业务领域进行细分，当领域被细分到一定程度后，DDD会将要解决的问题范围限定在特定的边界内，并在这个边界内构建领域模型，进而用代码实现该领域模型，解决相应业务领域的应用建设问题
在领域细分过程中，你可以将领域分解为子域，子域还可以继续分为子子域，一直到你认为这个子域的大小，正好适合你的团队开展领域建模工作为止
中台本质
提炼各个业务板块的共同需求，进行业务和系统抽象，形成通用的、可复用的业务模型，打造成组件化产品，供前台部门使用。
前台要做什么业务，需要什么资源，就可以直接找中台，而不需要每次都去改动自己的底层
DDD与中台的联系
分支主题
DDD重构中台模型策略
自上而下策略
适合全新的应用系统建设，或遗留系统推倒重建的建设模式
自下而上策略
适合遗留系统领域模型的演进式重构，也适合单体应用向微服务架构演进
0 条评论
下一页
