这个功能应该谁来做?

·  阅读 1712

跨部门开发,总会有一些参数转换逻辑会涉及双边的领域逻辑,这些转换逻辑到底应该谁来做呢?下面使用一个简单的实例来演示下争议的过程,并给出一定的思考。

1. 争议举例需求背景

用户购买「买一赠一」两件商品,「促销部门」关心分别独立的两个商品(不同商品价格和促销不一样),「库存部门」不关心买一赠一,告诉我扣减两件库存就可以,「结算部门」调用「库存部门」的接口到底应不应该把「买一赠一」合并商品数量为二呢?

2. 方案一:结算作为「胶水层」

  • 库存域(部门):认为自己提供API,使用方根据自己API来拼接参数(库存不关心主赠,只关心数量,按照库存的标准来合并数量)
  • 促销域(部门):认为自己提供API,使用方根据自己API来拼接参数(促销关心主赠,按照促销的标准不合并数量)
  • 结算页部门:大家都认为结算是胶水层,理所应当衔接每个交易子域,结算部门调用每个系统前都需要根据需要加工参数,结算页需要学习各个子域的接口隐含知识。

胶水层示例.png

3. 结算作为胶水整体架构

整体形成每个子域很舒服,是大爷;结算页需要学习每个子域的不同,进行包装,并且每个子域的变化,结算页都需要进行响应。

胶水层架构.png

4. 方案二:结算页是核心业务子域,对等架构

如果结算域认为自己和库存一样也是核心业务域,认为自己不应该耦合其他域呢?

  • 结算页制定「通用模型标准」,传递每个交易子域都是「通用模型」,每个子域的变化波及结算的概率变低。
  • 每个子域比如「库存」,「促销」自己把结算页的「通用参数」转换为自己需要的格式。
  • 每个子域比如「库存」,「促销」需要学习结算的「通用的模型标准」。

对等架构.png

5.方案二应用到示例

上面的示例,改变为结算页传递库存和促销都是两个苹果,库存和促销自己决定要不要合并。

  • 更加灵活:如果库存出现同一个商品不需要合并的场景,或者需要部分合并的场景,结算页不会感知。

对等示例.png

6.方案对比

方案一:简单,直接,原始。

  • 胶水和核心业务域界限分明,变化集中在胶水层。
  • 伴随业务复杂度提升,胶水层职责会越来越多,会引起胶水层的复杂度升高难以维护。

方案二:复杂,灵活。

  • 管理沟通难度上升:胶水层升级业务域,对等架构,对等架构要求不同部门认可「通用模型」。
  • 应对复杂业务整体更稳定:逻辑集中在具体子域,每个子域针对需求分别做出响应更专业和内聚。
  • 难点:不同业务域的「通用模型」的合理性。

7.方案二中「通用模型」的悖论与思考

通用模型与子域划分相悖

划分不同子域的初衷是为了不同子域可以独立设计「子域专有模型」,彼此互不影响,从这个角度看,子域划分是反对「通用模型」的,事实上并不存在放在哪里都适用的通用模型,这一点需要说明白。

局部通用模型

那么方案二的「通用模型」到底是什么?虽然不存在哪里都通用的模型,如果我们加个范围,交易的几个子域呢(不算财务等相差太大的子域)?是不是就有可能存在交易的几个子域可以一定程度上复用的「通用模型」呢?

如下图:更近一步,可以在「通用模型」的基础上,适当改造,消除每个子域必然不关心的属性,形成介于「通用模型」和「专有模型」之间的适合沟通的模型,产生每个子域的通用模型(比如「库存通用模型」,「促销通用模型」)

通用模型.png

不同的方案都有自己的生命力,适用于不同的场景,很难用一句「好」与「坏」来评判。

分类:
后端
标签:
分类:
后端
标签:
收藏成功!
已添加到「」, 点击更改