领域驱动设计逐渐成为一个开发人员用于炫耀的口号。很多没有受过基本软件工程训练的开发人员，打着领域驱动设计的大旗胡作非为，大有重演敏捷一幕的味道。本演讲结合软件工程历史文献，剖析领域驱动设计所使用的热门用语中，哪些是带来进步的，哪些是“重新包装”的，哪些是“因为无知而重新发明”的，哪些是无用的。

演讲提纲：

1. “领域（Domain）”用语溯源和评价
2. “通用语言(Ubiquitous Language)”用语溯源和评价
3. "战略（Strategic）"、“战术（Tactics）”用语溯源和评价
4. “限界上下文（Bounded Context）”用语溯源和评价
5. “聚合（Aggregate）”用语溯源和评价
6. “事件溯源（Event Sourcing）”、“事件⻛暴（Event Storming）”用语溯源和评价

听众受益点：

1. 更深刻理解领域驱动设计本质
2. 有助于在实践中有效使用

DCI是数据、场景、交互（Data、Context、Interactions）简称，重点是关注数据的不同场景的交互行为，是面向对象系统状态和行为的一种范式设计；DCI在许多方面是许多过去范式的统一，多年来这些模式已经成为面向对象编程的辅助工具。

问题背景：电信软件的功能复杂特性交叉，对实时性和数据一致性的要求比较高，代码规模比较大，同时处理大量并发活动。

解决方案选型：1.领域建模＋贫血模型；2.领域建模＋充血模型；3.领域建模＋DCI。

方案介绍：选择“领域建模＋DCI”，将类和对象看成不同的事物。类作为一种模块化手段，遵循高内聚，低耦合，让软件易于应对变化；将类看做是领域对象拥有的职责或扮演的角色，对象作为一种领域对象的的直接映射，解决了过多的类带来的可理解性问题，让领域可以指导设计，设计真正反映领域。如果使用 C++ 语言来实现的话，可以通过多重继承的方式来完成职责 ROLE 的组合 ；如果使用Go语言来实现的话，可以通过依赖注入的方式完成职责 ROLE 的组合。

实施后效果说明：DCI 可以和 DDD 融合在一起，基于职责的组合式设计提高了代码的可理解性和应对变化的能力，而且对于开发人员来说 DCI 带来的收益比 DDD 更大。

演讲提纲：

1. DCI 架构模式
   • Data，Context，Interaction
   • 优缺点
2. DCI 是 DDD 的补充
   • 类与对象的关系
   • DCI 与 DDD 的融合
   • ROLE 的建模
   • 数据依赖管理
   • 领域模型各部分的可组合性
3. 实践案例
   • 案例介绍
   • 物理设计
   • 领域模型设计
   • 代码实现要点
4. 小结
   • DCI 与 DDD 的融合
   • 审视类与对象的关系
   • DCI 落地的核心是 ROLE 的建模
   • 对于开发人员来说 DCI 的收益比 DDD 更大

听众受益点：

1. 理解 DCI 架构模式
2. 明白 DDD 和 DCI 的关系
3. 清楚团队基于 DDD 落地 DCI 的方法

围绕在罗辑思维后端所经历的一次较大规模的系统重构展开的，用实例来说明领域驱动设计带来的帮助启发和指导。整理为了三个部分，第一部分是“用领域驱动来把握真正的业务需求”，第二部分简单介绍一下“领域驱动设计指导系统架构设计与建模”，第三部分是“用限界上下文来保护领域”。

演讲提纲：

1、用领域驱动来把握真正的业务需求

• 商家视角的电商业务基本流程
• 业务需求让网状调用关系加剧
• 订单代理系统是个技术目标，业务不关心
• 用领域驱动来找到业务的真正需求

2、领域驱动设计指导系统架构设计与建模

• 电商的基本业务模型
• 如何用DDD使得从“小商贩”变为“超市卖家”

3、用限界上下文来保护领域

• 为什么要重视限界上下文
• 保护领域的依据与目标
• 保护领域的实践与带来的收益

听众受益点：

领域驱动设计战略部分的落地运用，重构或者新开发复杂业务系统时，如何把握到真正的业务需求，如何围绕着业务需求和技术目标，利用领域来更合理的建模和设计，用限界上下文来保护领域。