致力于提升研发企业的持续创新能力

培训目标

需求分析人员和领域专家无法与团队的设计人员和开发人员进行有效沟通。需求分析人员不了解软件设计，软件设计人员常常会曲解需求内容，这是软件开发中容易出现的第一病症。它带来的后果是设计频繁变更，设计的软件不满足客户需求。

需求分析虽然明白无误，设计人员却无法准确地抽象领域模型，从而不能开展有效的软件设计，这是软件开发中容易出现的第二病症。它带来的后果是设计质量糟糕，开发的代码不具有良好的可读性，增加了软件的开发与维护成本。

系统的业务需求复杂多变，设计人员却总是喜欢从实现角度以及数据库层面思考业务问题，这是软件开发中容易出现的第三病症。它会导致开发的系统过于复杂，且可扩展性差，无法有效应对需求发生的变化。

本次培训的内容——领域驱动设计正好是解决这三种常见病症的最佳药方。

培训计划

第一单元：领域驱动设计过程

本部分内容总结了领域驱动设计的基本要素与特征，然后从整体讲解贯穿战略式设计到战术式设计的整个设计过程。其中，战略部分内容包括：

• 统一语言的价值：沟通与协作是领域驱动设计的主旋律，领域专家与开发团队都应该在统一语言的指导下进行交流，并在模型中得到体现。
• 战略设计的关键要素：战略设计模式中的限界上下文是领域驱动设计的核心模式，它对系统架构起到了核心的支撑作用
• 领域与限界上下文之间的关系：领域、子领域与限界上下文之间的关系，是问题域与解决方案域之间的关系映射。

案例：识别集装箱多式联运系统的统一语言对建立领域模型的帮助

战术部分内容包括：

• 领域模型驱动设计：介绍领域模型驱动设计从分析到设计到实现的整体过程与方法
• 战术设计要素：介绍实体、值对象、聚合、资源库、工厂、领域服务之间的关系

第二单元：战略设计的核心议题

限界上下文

限界上下文是领域驱动设计的核心，也是战略式设计的入口。限界上下文还能与微服务架构有机结合，帮助我们获得物理架构与逻辑架构。内容包括：

• 限界上下文的意义
• 理解限界上下文的本质
• 分析限界上下文的边界
• 上下文映射
• 事件风暴探索业务全景

案例：集装箱多式联运系统的限界上下文识别 
演练：通过事件风暴探索业务全景，识别限界上下文，确定上下文映射

分层架构模式

DDD对经典的分层架构模式进行了改进，提出了自己独有的四层架构。结合依赖倒置原则，DDD社区对原有DDD分层架构又进行了改进，而这种改进又与领域建模息息相关：

• 整洁架构思想
• 分层架构的演进
• 层次的职责与分离

案例：EAS系统的系统架构

第三单元：战术设计的核心议题

领域模型驱动设计

从领域分析建模到设计建模再到实现建模，整个过程将在限界上下文的边界控制下围绕着“领域”为核心驱动力，在统一语言的指导下进行。内容包括：

• 建模的范式
• 事件风暴的领域分析建模方法
• 领域驱动设计的角色构造型

演练：通过事件风暴进行领域分析建模

聚合与资源库

聚合是战术设计的核心，也是设计中较难掌握的概念。在识别聚合边界时，要么边界过大，要么边界过小，主要原因还是没有理解聚合的意义。一旦确定了聚合，就可以定义操作聚合的资源库。内容包括：

• 聚合用于维护多个实体与值对象的边界
• 设计聚合的原则
• 聚合的内部关系
• 聚合之间的关系
• 资源库设计的最佳实践

案例：供应链系统订单聚合的设计 
案例：OfBiz供应链系统的模型分析

场景驱动设计

利用场景驱动设计方法将DDD的战术设计要素结合起来，确定限界上下文内领域服务、实体、值对象、资源库和聚合。整个场景驱动设计过程包括：

• 识别场景
• 分解任务
• 分配职责

演练：选择领域场景进行场景驱动设计

第四单元：Case Study

Case Study的案例模拟一个在线教育平台，整个演练贯穿整个工作坊，并以事件风暴为主线，由学员进行业务全景探索与领域分析建模。