DDD解决软件系统腐化之道

前言

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

腐化之谜

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

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

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

参考计算机系统架构：

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

因而咱们能够在架构角度参考计算机系统架构的实现。

架构建模

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

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

DDD带来的不一样：

1. 将原有以技术角度审视架构演进的视角，转换到以业务视角切入架构。
2. 业务复杂度来源于领域自己，深刻领域，正确识别出领域深层次概念及关系。
3. 将领域知识进行结构性表达，同时与编程模型保持一致，便造成了DDD。

基于问题空间的DDD模式

基于解空间的DDD模式

界限上下文

由显示边界限定的特定内聚职责，领域模型便存在于上下文以内。

界限上下文识别过程：

领域分析

如何经过真实业务驱动需求演化出DDD模型呢？

能够采用事件风暴进行领域分析。

流程：

1. PM，运营，RD共聚一堂
2. 数小时内理解复杂领域
3. 标记简单的UML
4. 工做流程与DDD完美匹配
5. 事件流演化

以电商系统为例

事件风暴 事件：PM关心真实事件 如：用户订单已发布，商品已发布 说明：关注点在于什么领域模型发生了什么变化。

命令风暴 命令：经过什么活动产生了事件 如：用户提交了订单，开放平台同步商品 说明：命令帮助咱们明确系统对外提供的能力，同时明确业务上的输入 命令来源：用户UI界面的操做，外部系统调用触发，定时任务触发

寻找聚合 聚合：一组相关性领域模型的聚合，用来封装业务不变性，确保关联紧密的领域模型内聚在一块儿 如：订单和商品 聚合的目的在于业务内聚，强迫RD进行简化领域模型的关联，实现业务设计高内聚低耦合的目的

划分界限上下文

1. 业务模型的问题是否同一个，是则放在同一个界限上下文中
2. 若是一个聚合同时解决了多个问题，则须要定义不一样的上下文肯定解决特定问题

界限上下文以内能够自由选择架构模式，如MVC，CQRS，微服务，SOA等。

不是全部界限上下文都采用领域驱动方式，非核心子域可参考数据驱动下的面向过程编程。

提取出面向切面的聚合层，以工程技术因素为主要考虑点。

DDD的核心价值在于指导划分界限上下文。

DDD分层设计

领域模型建设思路：

1. 业务与技术关注点分离，依赖倒置，内部不依赖于外部且外部可替换
2. 接口适配器架构
3. 防腐层建设，领域模型依赖稳定性

参考六边形架构：

架构目标：

• 独立于框架
• 与数据库分离
• 可测试性
• 与外部结构分离
• 与UI分离

架构原则：

• 关注点分离，切割不一样层
• 依赖原则：外部依赖内部，依赖倒置
• 架构设计围绕用例

结合CQRS设计

CQRS：命令查询职责分离

将更复杂的领域模型拆分为读取和写入两部分。 将消息传递，数据日志同步，领域事件和事件溯源使用到特定上下文。

领域驱动实践

目前咱们活动营销系统中，存在大量迭代需求都是针对运营需求所设计，需求自己具备复杂性和持续迭代性，故均已转换采用领域驱动设计方式实现。

对现有及可预期的玩法需求进行了逻辑抽象，提供了统一业务领域玩法模型，为运营提供统一玩法配置管理平台，进行玩法需求配置，通过领域系统内核进行集成，对用户输出统一玩法活动UI及流程。

在局部演进及扩展需求，采用元数据+大字段应对信息的不肯定性，流程引擎+规则引擎构造玩法，DSL提供动态建立玩法资源配置的能力。

梳理事件风暴，抽象命令风暴，寻找履行命令的业务名词，对相似的名词玩法进行共性提取，作合适的抽象，同时创建通用语言描述及定义。

采用DDD分层架构+六边形架构+CQRS模型，使得系统具有面向领域驱动的演进能力。

最后

DDD不是银弹

哪些产品适用于DDD：

1. 是不是复杂问题，或者子域内具备复杂性
2. 业务是否重要且有很高的预期
3. 是否可让运营和PM介入
4. 遵循迭代式的开放方法

领域模型好坏的标准：

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