课程简介
领域驱动设计案例实战训练营建立了完整的领域驱动设计统一过程，围绕着领域为核心驱动力，引入需求分析、架构设计与领域建模的最佳实践，在敏捷迭代开发模式的规范下，为团队提供了一套规范而完整的参考过程体系，旨在解决需求分析与软件设计的不一致问题，解决领域建模与程序实现的不一致问题，控制业务复杂度与技术复杂度，为业务复杂的企业系统提供行之有效的设计解决方案。
目标收益
通过本次实战训练营，可以实现以下目标收益：
1、理解和掌握领域驱动设计方法体系
2、深入分析面向对象设计知识与设计模式
3、需求分析与领域建模技术
4、战略层面的软件体系架构设计以及微服务架构设计
5、应用服务、领域逻辑以及基础设施的编程实现
培训对象
课程大纲
| 第一部分 领域驱动设计体系 |
以高屋建瓴的方式概括讲解整个领域驱动设计体系，内容包括： 领域驱动设计体系基础 领域驱动设计统一过程 快速介绍和解读由Eric Evans提出的领域驱动设计体系，了解该方法体系与软件研发生命周期之间的关系，给出领域驱动设计提倡的研发过程，简要介绍它的主要模式。 对比用例驱动的面向对象分析与设计方法、ICONIX方法，提炼经典领域驱动设计体系存在的不足，结合讲师丰富的项目经验与咨询经验，提出领域驱动设计统一过程，包括需求分析、架构设计与领域建模等内容，并在领域驱动设计的指导原则下进行。 在领域驱动设计统一过程的指导下，我提出了由十二个步骤构成的服务风暴的平行模型，为固化领域驱动设计的过程提供了规范过程与指导原则。 案例分析 Apache OFBiz是一个开源的、基于J2EE和XML规范的框架，用于构建大型企业级、跨平台、跨数据库、跨应用服务器的多层、分布式电子商务类WEB应用系统。OFBiz采用了MVC模式，并贯穿于业务层和数据层，是典型的采用数据驱动设计的软件项目，广泛采用了违背面向对象设计原则的贫血模型与事务脚本模式，这些实践正是领域驱动设计要竭力避免的。 |
| 第二部分 全局分析阶段 |
对整个项目进行业务的全局分析，内容包括： 统一语言 全局分析6W模型 业务流程分析 识别和编写业务服务 划分子领域 业务架构 统一语言是贯穿整个问题空间到解空间的重要模式，有利于领域专家与开发团队的共同协作，形成领域知识在整个团队之间的传递。它也是全局分析阶段最重要的业务知识分析基础，它与领域模型之间存在相辅相成的关系。 全局分析6W模型涵盖了整个全局分析阶段，了解该模型，可以帮助领域专家、团队负责人与架构师共同确定整个系统的问题空间，确定利益相关者、系统愿景和系统范围，确定价值需求和业务需求之间的关系，梳理业务流程，识别业务服务，建立反映整个系统的业务架构。 业务服务是基本的业务分析单元，是全局分析阶段的核心模式，也是识别子领域的主要输入。本阶段将主要围绕业务服务展开讲解、演练和分析，并通过实际案例对比了业务服务与用例之间的区别。 案例讲解 对比WMS系统的“收货”用例，说明业务服务与用例之间的区别，进而获得对应的业务服务图，并按照规定格式编写业务服务规约。 案例演练 识别购票业务流程的业务服务 模拟在铁路12306APP的整个购票流程，根据业务服务的定义梳理出贯穿整个流程的所有业务服务。 识别技术部落的子领域 目标：搭建一个技术部落（TRIBE），将与IT、互联网、数字领域相关的人、部落（业务、社区、兴趣组等）和内容联系起来，提供一个分享与交流的途径。在最基本的层面上，它是一个本地的博客、微博、微信文章、开源代码、活动、讲座、工作以及更多内容的聚合器。 根据讲师提供的业务服务，按照服务风暴的全局分析过程，演练如何正确地识别子领域，建立系统的业务架构。 |
| 第三部分 架构映射阶段 |
在领域驱动的战略设计阶段，以领域为核心驱动力，以限界上下文为核心模式构建面向领域的架构体系，内容包括： 限界上下文 菱形对称架构 上下文映射 系统上下文 领域驱动架构风格 结合软件复杂度的本质分析与软件架构的定义，剖析领域驱动设计对架构战略的应对方式，引出战略设计的核心模式——限界上下文。限界上下文作为业务能力的纵向切分、领域模型的知识语境，是响应业务变化的关键架构因素。由限界上下文之间的协作形成上下文映射，并根据领域驱动设计原则，建立以菱形对称架构与系统分层架构为支撑的领域驱动架构风格。 架构映射阶段仍然遵循服务风暴的设计过程，并以全局阶段输出的业务架构为主要输入，获得限界上下文组件图、服务序列图以及遵循菱形对称架构和系统分层架构的应用架构，完成从业务架构到应用架构的映射。 案例分析 全球地面航班保障平台是某航空公司的核心系统建设目标，在设计该系统的整个解决方案时，运用了领域驱动设计统一过程，实现了从业务架构向应用架构的映射，包括通过业务服务识别限界上下文的映射过程，通过服务序列图确定上下文映射模式，定义服务契约，获得整个系统的逻辑架构，然后针对客户案例指导团队进行架构设计，输出实践结果。 案例演练 以全局分析阶段输出的技术部落业务架构为输入，开展架构映射工作坊，结合讲师给出的识别限界上下文的检查项（checklist）对组成业务架构的业务子域做进一步调整，将其映射为限界上下文，然后，根据讲师给出的“报名活动”业务服务规约，绘制服务序列图，推导出多个限界上下文之间的协作关系，定义API契约，并绘制出限界上下文组件图，最终得到整个系统的应用架构。 |
| 第四部分 领域建模阶段 |
以业务服务为建模核心开展领域模型驱动设计，是保证领域驱动设计落地的重要条件，内容包括： 领域分析建模 领域设计建模 领域实现建模 在限界上下文的知识边界内分析领域逻辑，提炼领域概念，在统一语言的指导下迭代地进行领域建模，包括建立清晰表达了领域概念的领域分析模型，与以聚合为核心要素的领域设计模型，通过服务驱动设计确定每个领域模型对象的职责，并顺利地引导到领域实现建模，以测试驱动开发的流程编写领域实现代码与测试代码。 领域建模阶段需要掌握或了解如下方法： 快速建模法 角色构造型 聚合的设计 服务驱动设计 测试驱动开发 整个建模阶段的输入是业务服务规约，而作为应用架构组成元素的限界上下文则规定了领域模型的边界。领域模型分为由聚合组成的静态领域模型和由序列图组成的动态领域模型，并由服务驱动设计将这些知识和方法串联起来。 案例分析 展示信用卡分期系统/EAS系统的领域建模过程，包括通过快速建模法获得领域分析模型，建立以聚合为基本设计单元的领域设计模型，服务驱动设计获得的序列图脚本，并展示如何通过测试驱动开发进行领域实现建模，然后针对客户案例指导团队进行领域建模，最终输出由文本、图与代码构成的领域模型。 案例讲解 超市收银业务场景的模型演进 领域驱动设计的建模基础是面向对象分析与设计，通过超市收银业务场景的模型演进，帮助学员进一步理解面向对象设计的基本原则，并在良好的面向对象设计基础之上，演示领域驱动设计对面向对象设计的增强。 结算系统领域建模设计的改进 在⼀个结算系统中，业务需求要求能够导⼊各种结算账单的Excel模板⽂件，然后通过具体的值填充这些报表模板，⽣成最终客户需要的Excel报表。团队采用经典的领域驱动设计过程，针对该业务场景获得了领域模型以及相应代码。然而，设计获得的领域模型体现了设计者对领域驱动设计的认识偏差。本案例演示了如何通过对正确地概念理解逐步改进整个模型的设计。 批量代付业务的领域建模 通过为批量代付业务定义和识别正确的业务服务，讲解从领域分析建模到领域设计建模、领域实现建模的全过程。 案例演练 在架构映射阶段获得应用架构基础上，选择“报名活动”等三个业务服务，利用快速建模法迅速获得领域分析模型，并识别出以聚合为核心的静态设计模型，然后开展服务驱动设计，获得序列图脚本，为进一步的测试驱动设计提供重要的设计输入。 |
| 第五部分 领域驱动设计的发展 |
领域驱动设计自2003年诞生一来，随着架构师与研发团队对它的认识愈发深入，又经过社区的不断推动，整个方法体系得到了不断地补充与完善，并将其运用到更加广泛的领域，这些内容包括： 事件风暴 事件溯源 微服务 事件风暴是一种提倡高度协作的可视化建模方法，可以通过它开展全局分析，在团队内部建立统一语言，探索业务全景，并建立领域分析模型，整个探索过程包括： 识别代表业务全景的领域事件 标记代表问题、重要关注点的热点 为每个领域事件识别参与者 识别限界上下文 确定上下文映射 在限界上下文内部定义领域分析模型 事件溯源（Event Sourcing）模式是为事件建模范式提供的设计模式，其中，领域事件与聚合成为领域设计模型的核心要素，在编程范式上与经典的领域驱动设计存在较大区别。本部分内容为讲解： 领域事件的定义 面向聚合的事件溯源 命令查询职责分离（CQRS）架构模式 事件驱动架构的发展与变化 微服务模式能够更好地契合云原生应用的架构，而领域驱动设计又为微服务的设计提供系统型指导，如引入限界上下文作为微服务的设计边界，我提出的菱形对称架构能够更好地管理和控制微服务之间的协作机制，并有助于针对单体系统到微服务系统的演进与重构。本部分内容讲解： 微服务的架构特征 限界上下文与微服务 绞杀者模式与微服务重构 案例讲解 运用事件风暴分析订单业务流程 以电子商务的典型订单流程，运用事件风暴驱动对事件的识别，帮助理解如何在实际项目中运用事件风暴，掌握事件风暴工作坊的设计要点和设计要素。 库存管理系统从单体到微服务架构 某零售商核心系统——库存管理系统是一个基于.NET开发的单数据库单体系统，随着门店的不断增加，该系统越来越不能满足用户、商品和订单增长的需求，企业在数字化建设的要求下，运用了领域驱动设计方法结合绞杀者模式完成了从单体到微服务架构的平滑升级。 案例演练 为学课堂 作为一个e-learning系统，覆盖从选课、诊断、试卷、批改、报名、支付、售后全流程，组织学员开展事件风暴工作坊，内容覆盖领域驱动的战略设计和战术设计，并以微服务架构设计为学课堂的整体架构，尝试运用事件驱动架构控制微服务之间的协作。 |
| 第六部分 领域驱动设计的价值 |
领域驱动设计作为一套完整地覆盖需求分析、架构设计到编码实现的软件工程设计方法，它的价值主要体现在： 完整而统一的设计过程和模式 追求高质量设计与编码的领域驱动设计架构风格 通过分而治之控制业务复杂度与技术复杂度 设计原则和模式称为团队共同遵守的研发纪律 以领域驱动设计统一过程和服务风暴的平行模型进一步总结领域驱动设计的重要内容，并推导出成功应用领域驱动设计的两大要素： 边界是核心 纪律是关键 本部分培训内容还总结了领域驱动设计统一过程三个阶段的主要交付物，并整理了运用领域驱动设计的常见反模式，通过对比这些不好的设计，进一步了解该如何正确地运用领域驱动设计。 |
|
第一部分 领域驱动设计体系 以高屋建瓴的方式概括讲解整个领域驱动设计体系，内容包括： 领域驱动设计体系基础 领域驱动设计统一过程 快速介绍和解读由Eric Evans提出的领域驱动设计体系，了解该方法体系与软件研发生命周期之间的关系，给出领域驱动设计提倡的研发过程，简要介绍它的主要模式。 对比用例驱动的面向对象分析与设计方法、ICONIX方法，提炼经典领域驱动设计体系存在的不足，结合讲师丰富的项目经验与咨询经验，提出领域驱动设计统一过程，包括需求分析、架构设计与领域建模等内容，并在领域驱动设计的指导原则下进行。 在领域驱动设计统一过程的指导下，我提出了由十二个步骤构成的服务风暴的平行模型，为固化领域驱动设计的过程提供了规范过程与指导原则。 案例分析 Apache OFBiz是一个开源的、基于J2EE和XML规范的框架，用于构建大型企业级、跨平台、跨数据库、跨应用服务器的多层、分布式电子商务类WEB应用系统。OFBiz采用了MVC模式，并贯穿于业务层和数据层，是典型的采用数据驱动设计的软件项目，广泛采用了违背面向对象设计原则的贫血模型与事务脚本模式，这些实践正是领域驱动设计要竭力避免的。 |
|
第二部分 全局分析阶段 对整个项目进行业务的全局分析，内容包括： 统一语言 全局分析6W模型 业务流程分析 识别和编写业务服务 划分子领域 业务架构 统一语言是贯穿整个问题空间到解空间的重要模式，有利于领域专家与开发团队的共同协作，形成领域知识在整个团队之间的传递。它也是全局分析阶段最重要的业务知识分析基础，它与领域模型之间存在相辅相成的关系。 全局分析6W模型涵盖了整个全局分析阶段，了解该模型，可以帮助领域专家、团队负责人与架构师共同确定整个系统的问题空间，确定利益相关者、系统愿景和系统范围，确定价值需求和业务需求之间的关系，梳理业务流程，识别业务服务，建立反映整个系统的业务架构。 业务服务是基本的业务分析单元，是全局分析阶段的核心模式，也是识别子领域的主要输入。本阶段将主要围绕业务服务展开讲解、演练和分析，并通过实际案例对比了业务服务与用例之间的区别。 案例讲解 对比WMS系统的“收货”用例，说明业务服务与用例之间的区别，进而获得对应的业务服务图，并按照规定格式编写业务服务规约。 案例演练 识别购票业务流程的业务服务 模拟在铁路12306APP的整个购票流程，根据业务服务的定义梳理出贯穿整个流程的所有业务服务。 识别技术部落的子领域 目标：搭建一个技术部落（TRIBE），将与IT、互联网、数字领域相关的人、部落（业务、社区、兴趣组等）和内容联系起来，提供一个分享与交流的途径。在最基本的层面上，它是一个本地的博客、微博、微信文章、开源代码、活动、讲座、工作以及更多内容的聚合器。 根据讲师提供的业务服务，按照服务风暴的全局分析过程，演练如何正确地识别子领域，建立系统的业务架构。 |
|
第三部分 架构映射阶段 在领域驱动的战略设计阶段，以领域为核心驱动力，以限界上下文为核心模式构建面向领域的架构体系，内容包括： 限界上下文 菱形对称架构 上下文映射 系统上下文 领域驱动架构风格 结合软件复杂度的本质分析与软件架构的定义，剖析领域驱动设计对架构战略的应对方式，引出战略设计的核心模式——限界上下文。限界上下文作为业务能力的纵向切分、领域模型的知识语境，是响应业务变化的关键架构因素。由限界上下文之间的协作形成上下文映射，并根据领域驱动设计原则，建立以菱形对称架构与系统分层架构为支撑的领域驱动架构风格。 架构映射阶段仍然遵循服务风暴的设计过程，并以全局阶段输出的业务架构为主要输入，获得限界上下文组件图、服务序列图以及遵循菱形对称架构和系统分层架构的应用架构，完成从业务架构到应用架构的映射。 案例分析 全球地面航班保障平台是某航空公司的核心系统建设目标，在设计该系统的整个解决方案时，运用了领域驱动设计统一过程，实现了从业务架构向应用架构的映射，包括通过业务服务识别限界上下文的映射过程，通过服务序列图确定上下文映射模式，定义服务契约，获得整个系统的逻辑架构，然后针对客户案例指导团队进行架构设计，输出实践结果。 案例演练 以全局分析阶段输出的技术部落业务架构为输入，开展架构映射工作坊，结合讲师给出的识别限界上下文的检查项（checklist）对组成业务架构的业务子域做进一步调整，将其映射为限界上下文，然后，根据讲师给出的“报名活动”业务服务规约，绘制服务序列图，推导出多个限界上下文之间的协作关系，定义API契约，并绘制出限界上下文组件图，最终得到整个系统的应用架构。 |
|
第四部分 领域建模阶段 以业务服务为建模核心开展领域模型驱动设计，是保证领域驱动设计落地的重要条件，内容包括： 领域分析建模 领域设计建模 领域实现建模 在限界上下文的知识边界内分析领域逻辑，提炼领域概念，在统一语言的指导下迭代地进行领域建模，包括建立清晰表达了领域概念的领域分析模型，与以聚合为核心要素的领域设计模型，通过服务驱动设计确定每个领域模型对象的职责，并顺利地引导到领域实现建模，以测试驱动开发的流程编写领域实现代码与测试代码。 领域建模阶段需要掌握或了解如下方法： 快速建模法 角色构造型 聚合的设计 服务驱动设计 测试驱动开发 整个建模阶段的输入是业务服务规约，而作为应用架构组成元素的限界上下文则规定了领域模型的边界。领域模型分为由聚合组成的静态领域模型和由序列图组成的动态领域模型，并由服务驱动设计将这些知识和方法串联起来。 案例分析 展示信用卡分期系统/EAS系统的领域建模过程，包括通过快速建模法获得领域分析模型，建立以聚合为基本设计单元的领域设计模型，服务驱动设计获得的序列图脚本，并展示如何通过测试驱动开发进行领域实现建模，然后针对客户案例指导团队进行领域建模，最终输出由文本、图与代码构成的领域模型。 案例讲解 超市收银业务场景的模型演进 领域驱动设计的建模基础是面向对象分析与设计，通过超市收银业务场景的模型演进，帮助学员进一步理解面向对象设计的基本原则，并在良好的面向对象设计基础之上，演示领域驱动设计对面向对象设计的增强。 结算系统领域建模设计的改进 在⼀个结算系统中，业务需求要求能够导⼊各种结算账单的Excel模板⽂件，然后通过具体的值填充这些报表模板，⽣成最终客户需要的Excel报表。团队采用经典的领域驱动设计过程，针对该业务场景获得了领域模型以及相应代码。然而，设计获得的领域模型体现了设计者对领域驱动设计的认识偏差。本案例演示了如何通过对正确地概念理解逐步改进整个模型的设计。 批量代付业务的领域建模 通过为批量代付业务定义和识别正确的业务服务，讲解从领域分析建模到领域设计建模、领域实现建模的全过程。 案例演练 在架构映射阶段获得应用架构基础上，选择“报名活动”等三个业务服务，利用快速建模法迅速获得领域分析模型，并识别出以聚合为核心的静态设计模型，然后开展服务驱动设计，获得序列图脚本，为进一步的测试驱动设计提供重要的设计输入。 |
|
第五部分 领域驱动设计的发展 领域驱动设计自2003年诞生一来，随着架构师与研发团队对它的认识愈发深入，又经过社区的不断推动，整个方法体系得到了不断地补充与完善，并将其运用到更加广泛的领域，这些内容包括： 事件风暴 事件溯源 微服务 事件风暴是一种提倡高度协作的可视化建模方法，可以通过它开展全局分析，在团队内部建立统一语言，探索业务全景，并建立领域分析模型，整个探索过程包括： 识别代表业务全景的领域事件 标记代表问题、重要关注点的热点 为每个领域事件识别参与者 识别限界上下文 确定上下文映射 在限界上下文内部定义领域分析模型 事件溯源（Event Sourcing）模式是为事件建模范式提供的设计模式，其中，领域事件与聚合成为领域设计模型的核心要素，在编程范式上与经典的领域驱动设计存在较大区别。本部分内容为讲解： 领域事件的定义 面向聚合的事件溯源 命令查询职责分离（CQRS）架构模式 事件驱动架构的发展与变化 微服务模式能够更好地契合云原生应用的架构，而领域驱动设计又为微服务的设计提供系统型指导，如引入限界上下文作为微服务的设计边界，我提出的菱形对称架构能够更好地管理和控制微服务之间的协作机制，并有助于针对单体系统到微服务系统的演进与重构。本部分内容讲解： 微服务的架构特征 限界上下文与微服务 绞杀者模式与微服务重构 案例讲解 运用事件风暴分析订单业务流程 以电子商务的典型订单流程，运用事件风暴驱动对事件的识别，帮助理解如何在实际项目中运用事件风暴，掌握事件风暴工作坊的设计要点和设计要素。 库存管理系统从单体到微服务架构 某零售商核心系统——库存管理系统是一个基于.NET开发的单数据库单体系统，随着门店的不断增加，该系统越来越不能满足用户、商品和订单增长的需求，企业在数字化建设的要求下，运用了领域驱动设计方法结合绞杀者模式完成了从单体到微服务架构的平滑升级。 案例演练 为学课堂 作为一个e-learning系统，覆盖从选课、诊断、试卷、批改、报名、支付、售后全流程，组织学员开展事件风暴工作坊，内容覆盖领域驱动的战略设计和战术设计，并以微服务架构设计为学课堂的整体架构，尝试运用事件驱动架构控制微服务之间的协作。 |
|
第六部分 领域驱动设计的价值 领域驱动设计作为一套完整地覆盖需求分析、架构设计到编码实现的软件工程设计方法，它的价值主要体现在： 完整而统一的设计过程和模式 追求高质量设计与编码的领域驱动设计架构风格 通过分而治之控制业务复杂度与技术复杂度 设计原则和模式称为团队共同遵守的研发纪律 以领域驱动设计统一过程和服务风暴的平行模型进一步总结领域驱动设计的重要内容，并推导出成功应用领域驱动设计的两大要素： 边界是核心 纪律是关键 本部分培训内容还总结了领域驱动设计统一过程三个阶段的主要交付物，并整理了运用领域驱动设计的常见反模式，通过对比这些不好的设计，进一步了解该如何正确地运用领域驱动设计。 |
近期公开课推荐
