跨部门开发，总会有一些参数转换逻辑会涉及双边的领域逻辑，这些转换逻辑到底应该谁来做呢？下面使用一个简单的实例来演示下争议的过程，并给出一定的思考。
1. 争议举例需求背景
用户购买「买一赠一」两件商品，「促销部门」关心分别独立的两个商品（不同商品价格和促销不一样），「库存部门」不关心买一赠一，告诉我扣减两件库存就可以，「结算部门」调用「库存部门」的接口到底应不应该把「买一赠一」合并商品数量为二呢？
2. 方案一：结算作为「胶水层」
- 库存域（部门）：认为自己提供API，使用方根据自己API来拼接参数（库存不关心主赠，只关心数量，按照库存的标准来合并数量）
- 促销域（部门）：认为自己提供API，使用方根据自己API来拼接参数（促销关心主赠，按照促销的标准不合并数量）
- 结算页部门：大家都认为结算是胶水层，理所应当衔接每个交易子域，结算部门调用每个系统前都需要根据需要加工参数，结算页需要学习各个子域的接口隐含知识。
3. 结算作为胶水整体架构
整体形成每个子域很舒服，是大爷；结算页需要学习每个子域的不同，进行包装，并且每个子域的变化，结算页都需要进行响应。
4. 方案二：结算页是核心业务子域，对等架构
如果结算域认为自己和库存一样也是核心业务域，认为自己不应该耦合其他域呢？
- 结算页制定「通用模型标准」，传递每个交易子域都是「通用模型」，每个子域的变化波及结算的概率变低。
- 每个子域比如「库存」，「促销」自己把结算页的「通用参数」转换为自己需要的格式。
- 每个子域比如「库存」，「促销」需要学习结算的「通用的模型标准」。
5.方案二应用到示例
上面的示例，改变为结算页传递库存和促销都是两个苹果，库存和促销自己决定要不要合并。
- 更加灵活：如果库存出现同一个商品不需要合并的场景，或者需要部分合并的场景，结算页不会感知。
6.方案对比
方案一：简单，直接，原始。
- 胶水和核心业务域界限分明，变化集中在胶水层。
- 伴随业务复杂度提升，胶水层职责会越来越多，会引起胶水层的复杂度升高难以维护。
方案二：复杂，灵活。
- 管理沟通难度上升：胶水层升级业务域，对等架构，对等架构要求不同部门认可「通用模型」。
- 应对复杂业务整体更稳定：逻辑集中在具体子域，每个子域针对需求分别做出响应更专业和内聚。
- 难点：不同业务域的「通用模型」的合理性。
7.方案二中「通用模型」的悖论与思考
通用模型与子域划分相悖
划分不同子域的初衷是为了不同子域可以独立设计「子域专有模型」，彼此互不影响，从这个角度看，子域划分是反对「通用模型」的，事实上并不存在放在哪里都适用的通用模型，这一点需要说明白。
局部通用模型
那么方案二的「通用模型」到底是什么？虽然不存在哪里都通用的模型，如果我们加个范围，交易的几个子域呢（不算财务等相差太大的子域）？是不是就有可能存在交易的几个子域可以一定程度上复用的「通用模型」呢？
如下图：更近一步，可以在「通用模型」的基础上，适当改造，消除每个子域必然不关心的属性，形成介于「通用模型」和「专有模型」之间的适合沟通的模型，产生每个子域的通用模型（比如「库存通用模型」，「促销通用模型」）
不同的方案都有自己的生命力，适用于不同的场景，很难用一句「好」与「坏」来评判。
