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

领域驱动设计能够解决：

需求分析人员与开发团队的沟通问题

从需求到开发实现的设计问题

系统过于复杂导致代码难以维护的开发问题

培训计划

第一单元：领域驱动设计概览 案例：隔离业务复杂度和技术复杂度

第二单元：战略式设计 通用语言（Ubiquitous  Language）

演练：对订单系统编写用例 限界上下文（Bounded  Context）

演练：识别EAS系统的限界上下文 上下文映射图 (Context Map)

案例：确认EAS系统限界上下文的关系 架构模式

分层架构 (Layered Architecture)

六边形架构 (Hexagonal Architecture)

第三单元：战术设计 领域建模

演练：四色建模 实体与值对象 领域服务

案例：项目管理系统的实体与服务 聚合 演练：在线拍卖系统的聚合分析 工厂和资源库

领域事件 应用层设计 时序图

演练：EAS培训系统的时序图设计 第四单元：DDD实战演练

项目需求： 项目目标

培训目标

需求分析人员和领域专家无法与团队的设计人员和开发人员进行有效沟通。需求分析

人员不了解软件设计，软件设计人员常常会曲解需求内容，这是软件开发中容易出现 的第一病症。它带来的后果是设计频繁变更，设计的软件不满足客户需求。

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

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

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

第一单元：领域驱动设计概览

整体介绍领域驱动设计的过程，并从软件复杂度的角度讲解领域驱动设计的价值。

内容包括：

领域驱动设计过程

领域驱动设计对复杂性的应对

通过引入案例讲解领域驱动设计对复杂性的应对。案例包括：

限界上下文帮助架构的演进

项目管理系统的领域模型

第二单元：战略式设计

通用语言（Ubiquitous Language）

为了更好的理解需求，我们需要与领域专家一起梳理目标领域的通用语言，从而就领

域术语达成一致，并有利于领域建模。本部分将讨论诸多获得通用语言的方法，并给 出实例来说明通用语言对模型以及代码的影响。

内容包括：

获得通用语言的方法

通用语言对编码的影响

演练：对订单系统编写用例

限界上下文（Bounded Context）

若要进行领域建模，并将业务需求逐步演化为架构设计，则需要引入DDD（领域驱动

设计）的战略设计作为指导。用户故事地图与限界上下文可以很好地结合，帮助架构 师很好地识别各个子领域的概念边界与设计边界。如此则可以运用“分而治之”的思想 识别出整个系统的业务逻辑边界与物理边界。

本部分同时还讨论了诸多设计原则在Bounded   Context中的运用，探讨了Bounded Context的本质思想，强调Bounded   Context的边界，进而与微服务架构结合起来，即 Bounded  Context的设计其实就是微服务的设计。

内容包括：

Bounded Context的意义

识别Bounded Context

议题：Bounded Context的边界

本部分内容会讲解限界上下文之间主要存在的组织模式与集成模式，这其中包括防腐

层，开放服务调用等。利用上下文映射图，有助于识别上下文之间的关系，思考处于 上下文内领域模型之间的通信方式，从而帮助架构师驱动出最终的应用逻辑架构。

内容包括：

团队的组织模式

集成模式

Context Map案例分析

案例：确认EAS系统限界上下文的关系

架构模式

分层架构 (Layered Architecture)

分层架构模式是应用最为广泛的架构模式，它根据关注点分离的架构原则，针对表现

层、领域层和基础设施层进行层次分离。本次培训将以全新视角审视分层架构，针对 大型软件系统分析该如何进行分层架构设计。

内容包括：

DDD分层架构模式

Clean Architecture思想

依赖注入与贫血模型

六边形架构 (Hexagonal Architecture)

虽然分层架构仍然是运用最为广泛的架构模式，同时更是诸多架构模式的基础，但它

已不足以描述越来越复杂的分布式系统架构。由Cockburn提出的六边形架构

（Hexagonal   Architecture）是一种具有对称性特征的架构风格。在这种架构中，不同 的客户通过“平等”的方式与系统交互。该架构中存在两个区域，分别是“外部区 域”和“内部区域”。这种界定了明确内外边界的架构风格，更有利于架构师实现关注点 分离，并将关注重心放在适配器与通信端口上。

第三单元：战术设计

通过限界上下文，可以帮助我们分析系统的领域模型，包括系统的核心领域与子领

域。确定系统的核心领域与子领域可以帮助架构师合理分配资源（包括时间资源与人 力资源）。而对子领域的进一步识别，可以帮助架构师更好地识别可重用资源，包括 可重用的功能模块，确定技术栈，决定构建还是购买的架构战略。

本部分将讲解DDD中的核心概念，并引入四色建模来帮助我们进行领域建模。 内容包括：

DDD中的核心要素

运用四色建模法

领域模型的演进

演练：四色建模

对具体案例进行四色建模，寻找到重要的时标性对象和实体对象。

电信话单的四色建模

EAS系统培训管理的四色建模

实体与值对象

这两个概念都是领域对象的体现，二者的主要区别在于对“标识”的运用。本部分的内

容深入展开对实体标识的讨论，揭示实体的本质特征，挖掘实体的关键行为。通过识 别角色与职责对实现进行分析。

本部分内容还将通过深入讲解值对象的特征帮助我们分辨值对象与实体，使得我们可 以在领域驱动设计中有效地运用实体与值对象。本部分内容还包括持久化值对象，以 及领域驱动设计与ORM之间的关系。

内容包括：

实体的标识

避免贫血模型

角色、职责与协作

领域建模与数据建模

领域服务

通过讲解什么是领域服务，什么不是领域服务理清领域服务的概念，并讲解如何建模

领域服务。讨论领域服务和面向接口设计思想。 内容包括：

何时建模为服务

识别建模的坏味道

案例：项目管理系统的实体与服务

聚合

聚合是领域驱动设计最为重要的领域概念。本部分内容将深入探讨聚合的设计原则，

并辨别在聚合设计中可能出现的坏味道，并提出针对性的解决方案。这些原则和方案 包括：在一致性边界之内建模真正的不变量，设计小的聚合，通过唯一标识引用其他 聚合，在边界外满足最终一致性。

内容包括：

聚合维护多个实体、值对象的边界

案例研究

设计聚合的原则

演练：在线拍卖系统的聚合分析

工厂和资源库

工厂和资源库都是管理领域对象（实体、值对象和服务）生命周期的对象。工厂主要

针对内存中对象从无到有的创建过程，与设计模式的工厂模式基本相似。

资源库则分为面向集合的资源库与面向持久化的资源库。本部分内容将重点讲解与资 源库直接相关的技术细节，包括如何选择资源库的方式，如何针对聚合持久化资源 库，如何管理事务，以及分辨资源库与数据访问对象（DAO）之间的异同。

领域事件

事件驱动架构的主要对象即为领域事件，我们要分清在何时以及为什么要使用领域事

件，并对领域事件进行建模。通过讲解发布者­订阅者模式讲解如何在领域模型和限界 上下文中发布领域事件。同时，针对事件进行存储的Event   Source也与CQRS架构风 格直接相关。

内容包括：

事件的本质

事件带来的价值

应用层设计

作为为UI提供的应用服务，其目的在于管理和协调领域对象，并为领域对象提供横切

关注点的内容。好的应用服务设计不应该承担任何与领域逻辑有关的职责。应用层是 架构层面的外观与适配器模式的体现。它可以提高软件系统架构的可用性与简单性， 也能够更好地与面向服务架构或RESTful架构风格结合。

时序图

根据事先识别的Use  Case，为其绘制时序图，动态地寻找Application  Service到各种

领域对象之间的协作，以帮助我们寻找到遗漏的领域对象与设计对象。

演练：EAS培训系统的时序图设计

第四单元：DDD实战演练

项目需求：

企业应用套件（EAS）系统是一个根据某集团应用信息化的要求而开发的企业级应用

软件。本系统为用户提供大量简单，快捷的操作接口，集团相关部门能更快捷、更方 便、更高效地处理日常事务工作，并为管理者提供决策参考、流程简化，建立集团与 各部门、员工之间交流的通道，有效地提高工作效率，实现整个集团的信息化管理。

项目目标

实现集团企业应用信息化，包括人力资源信息管理、项目管理、客户关系管理等。具

体目标如下：

实现集团日常事务的信息化管理，包括工作日志、考勤、月度工作评价等；

解决客户业务需求与集团人员供应之间的矛盾，实现供需平衡，建立沟通的有效

通道；

实现项目的信息化管理，包括项目开发流程管理、项目人员信息跟踪、统计项目

信息等；

提供市场信息、人员信息、项目信息的统计，辅助管理者作出正确的决策。

项目要解决的问题：

公司市场信息、人员信息不畅通，无法实现人员供需平衡：“供”主要表现在各公

司富余人员信息、项目中快结束人员信息、人员招聘信息、学院培训人员信息等 不能有效反馈。“需”主要表现在已签约项目人员需求、意向项目人员需求、公司 计划人员需求等信息无法及时传递。“供”“需”脱节，信息不畅，不能快速有效的进 行供需求匹配。

公司各项配套管理问题。各职能部门不能及时获得“供需”信息，也就无法及时对 设备、住房、工位、资金进行配套协调管理。

辅助决策管理问题。公司领导决策层不能很好的把握全局，无法有侧重的进行资

源协调及工作支持，包括市场力度、人才管理、财务政策及公司日常管理。

客户信息共享及项目管理质量控制问题。无法跟踪项目人员的工作状态，可能导

致项目组成员以及项目质量的失控。

这是领域驱动设计过程的完整案例分析，从需求开始着手，开展对整个系统的架构分 析、领域概念识别与分析，并对建立的领域模型进行迭代与演化，核心领域概念的演 进，扫清领域设计过程中的认知障碍，并总结了领域驱动设计过程的一些经验教训。

本实战演练包含了真实的案例需求，以及符合领域驱动设计各种知识点的案例病症分 析，从对比入手来探讨好的领域驱动设计方法。同时，还将引入大量的可视化图形、 设计图与代码帮助学员理解如何在真实项目中运用领域驱动设计的思想，指导设计人 员进行良好的设计。