其他分享
首页 > 其他分享> > 系统腐化

系统腐化

作者:互联网

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. 防腐层建设,领域模型依赖稳定性

参考六边形架构:

架构目标:

架构原则:

结合CQRS设计

CQRS:命令查询职责分离

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

领域驱动实践

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

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

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

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

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

最后

DDD不是银弹

哪些产品适用于DDD:

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

领域模型好坏的标准:

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

更多交流:

标签:架构,玩法,模型,系统,领域,腐化,上下文,DDD
来源: https://www.cnblogs.com/Leo_wl/p/11013324.html