前言
任何人类的设计都会腐化，软件系统也不例外
腐化之谜
随着系统的规模增长和复杂度膨胀，系统会慢慢腐化。
于是改一个很简单的下单地址，就会牵动整个交易系统十几处的改动。
如何解决这种腐化之谜呢？
参考计算机系统架构：
一个复杂的计算机系统架构包括：软件系统元素，元素之间的联系，元素本身有自己特有属性。
于是我们可以在架构角度参考计算机系统架构的实现。
架构建模
为达到上面提到的架构建模的目的，引入领域驱动。
领域驱动围绕业务概念构建领域模型，通过分离技术的方式实现应对复杂业务，及系统难以演进问题的解决方案。
DDD带来的不同：
- 将原有以技术角度审视架构演进的视角，转换到以业务视角切入架构。
- 业务复杂度来源于领域本身，深入领域，正确识别出领域深层次概念及关系。
- 将领域知识进行结构性表达，同时与编程模型保持一致，便形成了DDD。
基于问题空间的DDD模式
基于解空间的DDD模式
界限上下文
由显示边界限定的特定内聚职责，领域模型便存在于上下文之内。
界限上下文识别过程：
领域分析
如何通过真实业务驱动需求演化出DDD模型呢？
可以采用事件风暴进行领域分析。
流程：
- PM，运营，RD共聚一堂
- 数小时内理解复杂领域
- 标记简单的UML
- 工作流程与DDD完美匹配
- 事件流演化
以电商系统为例
事件风暴
事件：PM关心真实事件
如：用户订单已发布，商品已发布
说明：关注点在于什么领域模型发生了什么变化。
命令风暴
命令：通过什么活动产生了事件
如：用户提交了订单，开放平台同步商品
说明：命令帮助我们明确系统对外提供的能力，同时明确业务上的输入
命令来源：用户UI界面的操作，外部系统调用触发，定时任务触发
寻找聚合
聚合：一组相关性领域模型的聚合，用来封装业务不变性，确保关联紧密的领域模型内聚在一起
如：订单和商品
聚合的目的在于业务内聚，强迫RD进行简化领域模型的关联，实现业务设计高内聚低耦合的目的
划分界限上下文
- 业务模型的问题是否同一个，是则放在同一个界限上下文中
- 如果一个聚合同时解决了多个问题，则需要定义不同的上下文确定解决特定问题
界限上下文之内可以自由选择架构模式，如MVC，CQRS，微服务，SOA等。
不是所有界限上下文都采用领域驱动方式，非核心子域可参考数据驱动下的面向过程编程。
提取出面向切面的聚合层，以工程技术因素为主要考虑点。
DDD的核心价值在于指导划分界限上下文。
DDD分层设计
领域模型建设思路：
- 业务与技术关注点分离，依赖倒置，内部不依赖于外部且外部可替换
- 接口适配器架构
- 防腐层建设，领域模型依赖稳定性
参考六边形架构：
架构目标：
- 独立于框架
- 与数据库分离
- 可测试性
- 与外部结构分离
- 与UI分离
架构原则：
- 关注点分离，切割不同层
- 依赖原则：外部依赖内部，依赖倒置
- 架构设计围绕用例
结合CQRS设计
CQRS：命令查询职责分离
将更复杂的领域模型拆分为读取和写入两部分。
将消息传递，数据日志同步，领域事件和事件溯源使用到特定上下文。
领域驱动实践
目前我们活动营销系统中，存在大量迭代需求都是针对运营需求所设计，需求本身具有复杂性和持续迭代性，故均已转换采用领域驱动设计方式实现。
对现有及可预期的玩法需求进行了逻辑抽象，提供了统一业务领域玩法模型，为运营提供统一玩法配置管理平台，进行玩法需求配置，经过领域系统内核进行集成，对用户输出统一玩法活动UI及流程。
在局部演进及扩展需求，采用元数据+大字段应对信息的不确定性，流程引擎+规则引擎构造玩法，DSL提供动态创建玩法资源配置的能力。
梳理事件风暴，抽象命令风暴，寻找履行命令的业务名词，对类似的名词玩法进行共性提取，做合适的抽象，同时建立通用语言描述及定义。
采用DDD分层架构+六边形架构+CQRS模型，使得系统具备面向领域驱动的演进能力。
最后
DDD不是银弹
哪些产品适用于DDD：
- 是否是复杂问题，或者子域内具有复杂性
- 业务是否重要且有很高的预期
- 是否可以让运营和PM介入
- 遵循迭代式的开放方法
领域模型好坏的标准：
- 模型反映了对于问题的抽象，抽象没有统一的标准
- 模型是迭代演进的，需要持续集成，改进
- 通用语言，领域模型和代码目标意图一致
更多交流：
