DDD应对运营活动系统腐化实践

前言

任何人类的设计都会腐化，软件系统也不例外

腐化之谜

随着系统的规模增长和复杂度膨胀，系统会慢慢腐化。

于是改一个很简单的下单地址，就会牵动整个交易系统十几处的改动。

如何解决这种腐化之谜呢？

参考计算机系统架构：

一个复杂的计算机系统架构包括：软件系统元素，元素之间的联系，元素本身有自己特有属性。

于是我们可以在架构角度参考计算机系统架构的实现。

架构建模

为达到上面提到的架构建模的目的，引入领域驱动。

领域驱动围绕业务概念构建领域模型，通过分离技术的方式实现应对复杂业务，及系统难以演进问题的解决方案。

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介入
遵循迭代式的开放方法

领域模型好坏的标准：

模型反映了对于问题的抽象，抽象没有统一的标准
模型是迭代演进的，需要持续集成，改进
通用语言，领域模型和代码目标意图一致

更多交流：

巴特西