400-626-7377
400-626-7377
领域驱动设计（DDD）是由Eric Evans提出的一种软件开发方法，其核心思想是将业务领域的核心概念、规则和流程作为软件设计的核心驱动力。通过深入了解业务领域，开发人员能够设计出更符合业务需求的软件系统，提高系统的可用性和可维护性。
DDD强调与业务专家紧密合作，共同建立领域模型，使软件设计能够准确反映业务领域的实际情况。领域模型是DDD的核心，它是对业务领域的抽象和表示，有助于开发人员深入理解业务领域，从而设计出更优质的软件系统。
DDD更加关注业务逻辑和领域模型的建模和实现，旨在解决复杂业务问题
MVC更加关注如何将应用程序分层，以便于管理和维护
DDD适用于复杂的业务领域，需要深入理解业务逻辑和领域模型的场景
MVC适用于对用户界面和数据交互进行有效管理的场景，如Web应用程序和桌面应用程序等
DDD通常以领域模型为核心，通过聚合、实体、值对象等概念进行组织和建模
MVC通过模型、视图、控制器的分离来组织应用程序，以实现更好的可维护性和可扩展性
DDD强调领域专家与开发团队之间的密切合作，通过沟通和协作来不断迭代和优化领域模型
MVC更加注重开发人员之间的分工合作，各个部分之间通过界面或接口进行通信
通过与业务专家紧密合作，开发团队可以更好地理解业务需求和业务流程
使用DDD可以创建更加灵活和可维护的代码，因为模型更好地反映了业务逻辑
DDD鼓励划分限界上下文，使得系统能够更好地应对变化
通过使用统一语言和明确的领域模型，开发人员能够更快地理解和实现业务需求
DDD的方法论可以帮助开发人员更好地把握业务核心，设计出更符合业务需求的系统架构
在DDD中，设计过程是自顶向下的，以业务为主导。帮助开发人员能够站在更高的视角，从业务需求出发，来规划和设计系统架构
对于涉及多个业务领域、具有复杂业务流程的大型系统，DDD能够帮助开发人员建立清晰的领域模型，提高系统的可维护性和可扩展性
DDD通过强调业务领域和软件设计的紧密联系，使得开发团队能够更快地理解业务需求，并快速调整软件系统以支持新的业务需求
剖析软件退化的根源，指明解决问题的方向
剖析DDD的设计思想
实践DDD的4大难题及真正作用
通过DDD来应对复杂系统的需求变更，实现高质量的软件设计，避免代码腐化
讲解DDD是如何解决软件退化等问题，为学员能够有效提高软件设计质量，提供了思路与方向
通过真实案例来一步一步讲解如何进行领域驱动设计
讲解如何通过领域驱动设计来指导软件变更，实现高质量的软件设计
通过大量真实的案例，讲解许多公司在开展领域驱动设计的过程中面临的难题、解决的思路以及最终的设计思想
获得由工业和信息化部教育与考试中心统一颁发
《领域驱动软件设计工程师认证》
案例：演示电商网站付款功能代码质量下降的过程
案例分析：揭示软件退化的根源
案例：演示嵌入式温控系统越来越难于维护的根源
案例分析：领域分析才是解决之道
案例：重新演练电商网站付款功能的变更过程
演练案例：在线订餐系统的领域设计过程
分组练习：按照事件风暴的步骤进行业务领域建模
实战演练：远程智慧医疗大数据平台设计过程
分组练习：按照领域模型进行设计开发
案例：在线订餐系统的应用
实战演练：高并发高可用的订单系统
案例：电商网站购物功能的设计
案例：电商网站下单服务的设计
案例：电商网站多渠道支付的微服务实现
案例：大数据与微服务结合的架构设计
案例：电商网站海量订单数据的秒级查询
案例：电商网站异步化操作的微服务实现
为什么我们需要领域驱动设计
1.现如今DDD越来越流行
2.DDD并不能帮助新项目的软件开发
3.DDD真正的作用是日后长期的维护
实践DDD的4大难题：
1.准确理解为什么要采用DDD？
2.怎样正确地进行业务领域建模？
3.怎样用领域模型指导开发与变更？
4.如何设计支持领域驱动的架构设计？
DDD真正的作用是应对日后的软件维护
1.我们现在面对的是快速变化的时代
2.变更越频繁，代码质量下降越快
案例：演示电商网站付款功能代码质量下降的过程
案例分析：揭示软件退化的根源
DDD的解决之道：业务领域建模
3.系统规模越来越大，系统越来越复杂
案例：演示嵌入式温控系统越来越难于维护的根源
案例分析：领域分析才是解决之道
DDD的解决之道：基于限界上下文拆分系统
案例分析：演示电商网站付款功能代码质量下降的过程
1.起初的设计
2.随后的变更
3.质量不断下降的过程
软件质量下降的根源：
1.软件总是因变更而变得越来越复杂
2.软件结构已经不再适应复杂的软件需求
3.必须要调整软件结构以适应新的软件需求
DDD的建模过程：
1.每次需求变更时先对需求进行领域分析
2.基于领域分析先进行领域模型的变更
3.基于领域模型的变更去指导程序的变更
DDD是应对软件复杂性之道
1.剖析领域驱动的设计思想
2.服务、实体与值对象的概念
3.充血模型与贫血模型的设计思路
4.问题域、子域与限界上下文划分
基于领域模型的设计变更
1.演练基于DDD的设计与变更过程
2.演练领域模型如何指导数据库设计
3.演练领域模型如何指导程序设计
4.聚合、仓库与工厂：傻傻分不清
5.限界上下文：系统拆分的利器
案例：重新演练电商网站付款功能的变更过程
第一个版本的领域模型与设计
第一次变更的分析设计过程
第二场变更的设计实现
第三次变更的设计实现
第四次变更与架构演化
领域建模分析过程
演练案例：在线订餐系统的领域设计过程
1.从领域中吸取知识
2.统一语言建模
3.事件风暴会议
1）梳理业务流程，识别领域事件
2）为每个领域事件识别参与者、行为、相关事物
3）标记事物之间的关系、聚合、聚合根
4）根据业务划分限界上下文
5）遍历所有事件，确定上下文映射
4.业务领域建模
1）为每个领域事件构建业务领域模型
2）划分主题域、支撑域、通用域
3）落实各子域之间的联系、接口及事件通知机制
基于领域模型的微服务设计
1.小而专的微服务设计
2.限界上下文与微服务拆分
3.上下文地图与微服务接口
4.各微服务中实体、值对象与服务的设计
5.各微服务中聚合、工厂与仓库的设计
6.领域模型4种关系3种继承的数据库设计
7.聚合层的设计、工厂和仓库的实现
8.基于DDD的微服务架构分层
解决DDD的设计难题
1.跨库查询的设计难题与设计实现
2.领域事件的通知机制与设计实现
3.微服务接口的防腐层设计
4.状态查询跟踪的设计思路与代码实现
分组练习：按照事件风暴的步骤进行业务领域建模
1. 召开事件风暴会议
2. 进行业务领域建模
3. 基于领域模型设计开发系统
实战演练：远程智慧医疗大数据平台设计过程
1.系统业务规划与战略设计
2.子系统→限界上下文→功能模块划分
3.由粗到细的用例建模
4.各子域业务领域建模
1）智慧诊疗数据模型的领域分析
2）诊所管理信息系统的领域分析
5.各子域的接口设计
1）上下文地图的模型分析
2）微服务接口的方案设计
6.微服务的技术落地实践
1）去中心化的技术治理
2）微服务的技术中台
3）微服务的云端应用平台
起初：一个传统的诊所管理系统向互联网转型
1）起初没有采用领域驱动设计，也运行了这么多年
2）现在向互联网转型，业务变得越来越复杂，怎么开始领域建模？
第一步：站在全局的系统建设规划
第二步：DDD战略设计与限界上下文划分
第三步：各子域的业务领域建模
第四步：上下文地图与各子域的接口设计
转型成互联网连锁诊所系统，又该如何分析设计
1）基于领域模型进行新需求的分析
2）基于领域模型进行原有代码的更新维护
3）基于限界上下文进行微服务的拆分，以及这个过程中的坑
第一步：基于DDD进行战略设计的调整
第二步：各子域的业务领域建模调整
第四步：上下文地图与各子域的接口设计
第五步：基于DDD的微服务拆分
Ø基于DDD的数据库设计与去中心化的数据治理
Ø如何由原有的贫血模型向现在的充血模型改造
Ø如何解决跨库的关联查询与事务处理
Ø如何实现领域事件的消息推送机制
Ø如何实现跨库的状态数据查询
Ø如何打造基于整洁架构的领域驱动设计框架
增加人工智能的智能诊疗数据模型
1）如何通过领域模型来开展数据智能业务
2）如何基于领域模型的规划与智能系统的接口
3）基于领域模型的微服务+大数据的设计实践
分组练习：按照领域模型进行设计开发
1. 基于领域模型进行微服务的拆分与设计
2. 基于领域模型进行每个微服务的数据库设计
3. 基于上下文地图形成微服务间的契约与接口
DDD需要强大技术架构支持
1.降低技术门槛，减少开发工作量 → 制订规范、合理分层、降低复杂度
2.易于业务变更，易于架构演化 → 将业务与技术解耦
3.支持领域驱动，支持微服务 → 通用仓库、工厂及基础设施的设计
4.平台不断完善，功能不断积累 → 敏捷架构设计：架构跑道与使能故事
支持DDD的技术架构建设思路
1.分析当前软件架构设计与架构演化的痛点与根源
2.阐述技术中台的建设思路
1）将业务与技术解耦 → 整洁架构与六边形架构
2）提取共性，精简业务代码 → 单Controller，单Dao
支持领域驱动+微服务的技术中台
案例：在线订餐系统的应用
1.通用、可配置的DDD仓库与工厂的设计
2.解决跨库的关联查询与事务处理
3.纯洁的Service与Entity便于不断地架构演化
现有系统的整洁架构转型
1.系统级的重构方法与步骤
2.建立接口层解耦业务代码与技术框架的过程
3.基于整洁架构的技术架构演化与快速交付
实战演练：高并发高可用的订单系统
微服务架构的6种设计模式
1.聚合模式
案例：电商网站购物功能的设计
Ø微服务前后端分离的设计
Ø分布式事务的两阶段提交
ØTCC方案与阿里Seata
演练：运用Seata实现微服务的分布式事务
Ø基于消息的最终一致性设计
演练：基于消息实现微服务的分布式事务
案例：电商网站下单服务的设计
单一职责原则与领域驱动设计
Ø互联网纵向切分在微服务的实现
Ø纵向切分应当注意的设计问题
Ø解决跨库关联查询的设计
演练：微服务间解决跨库关联查询的设计
2.代理模式
案例：电商网站多渠道支付的微服务实现
3.链式模式
4.分支模式
5.数据共享模式
案例：大数据与微服务结合的架构设计
案例：电商网站海量订单数据的秒级查询
6.异步消息模式
案例：电商网站异步化操作的微服务实现
微服务的拆分原则
1.能不拆尽量不拆：减少微服务间的调用
2.该拆分就得拆分
1）公共模块该拆分就得拆分
2）越来越复杂的模块该拆分就得拆分
