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介入
- 遵循迭代式的开放方法
领域模型好坏的标准:
- 模型反映了对于问题的抽象,抽象没有统一的标准
- 模型是迭代演进的,需要持续集成,改进
- 通用语言,领域模型和代码目标意图一致
更多交流:
标签:架构,模型,玩法,领域,运营,腐化,上下文,DDD 来源: https://www.cnblogs.com/lonelyxmas/p/10965648.html