系统间的七种关系

本节将根据耦合度从高到低逐一探讨这些关系。耦合度高有时并不是坏事，它能够让团队内部的系统更加内聚，而不是无法整合的碎块。我们应该根据具体情况进行选择。

因为系统间关系往往也是组织架构的反映，此处每种关系除了描述其相关的技术架构，本节也将描述其适用的组织架构。

七种系统间关系全部来源于《领域驱动设计》原著内容的总结和拓展。

共享内核（Shared Kernel）

系统间共享部分模型和相关逻辑，是最亲密的合作关系。

当负责这两个系统的团队存在非常紧密的合作关系（甚至就是同一个团队），并且业务上十分相似时，共享内核就是一个不错的选择。在职责上，即使共享内核有专门的 owner，其任何修改都需要经过多方探讨，因为其中的任何模型更改都会深刻地影响这几个系统。

最典型的就是业务系统以及业务相关的批量导入导出系统，两者虽然因为技术原因（隔离消耗资源的任务）被划分成了两个系统，但是它们的模型理论上应该完全共享的（即共享内核），这样才能保证业务上的修改及时反映到导入导出中。试想如果这种场景还用 ACL 做隔离的话，每次业务系统修改，还需要同步在导入导出模型中做修改，这将是非常麻烦的。

客户-供应方（Customer-Supplier）

两个系统虽然相对独立发展，但是底层系统（Supplier, 供应方）愿意为上层系统（Customer, 客户）的需求负责，并且做对应的变更。这也是一种非常亲密的合作关系，只比共享内核弱一点。

因为两个系统在实现时会互相考虑对方，此时两者交互部分的模型会非常相似，相比共享内核，它只共享一些模型，不共享逻辑代码。

遵奉者（Conformist）

两个系统完全独立发展，底层系统因为没有人力或者其他原因，不可能因为上层系统的需求做出任何变更。这与下文 ACL 适用的情况类似。

上层系统的模型设计与底层系统的模型严格地保持一致，虽然也是需要一个转换层转换，但是没有做任何“真正”的转换，最多只是简单的属性拷贝，这是和 ACL 的主要区别，ACL 会做更加复杂的转换。

防腐层（ACL）

ACL 对应的组织架构与遵奉者类似。

ACL 适合两种情况：

● 同样的概念在两个系统中有不同的含义：“用户”概念在 IM 中就是消息发起接受方，但是在钉钉通讯录中却是指某个组织内的、含有职位，角色等信息的职员
● 模型相差巨大：比如 excel 表格和钉钉文档中的表格

ACL 是指复杂的数据转换层，在转换数据时需要做概念上的翻译。

另谋它路（Separate Way）

“最好”的解耦方法就是完全另写一套代码。

这有点像阿里现在 “拆中台” 的思路，研究了半天，发现依赖复杂的中台，还不如业务团队自己写一套简单的系统实现。

这已经不能算是系统间关系了，是 “完全没有关系” 的意思。

开放主机服务（Open Host Service）与发布语言（Published Language）

直接举例，底层服务开放一个 Http 接口（开放主机服务），允许以 json 的数据格式（发布语言）进行调用。

它们其实就是开放 RPC 调用。他们被单独列出来完全是因为 《领域驱动设计》这本书成书较早，互联网软件比较少，RPC 也没有特别特别规范的标准。在微服务时代，限界上下文的调用几乎都通过 RPC 进行，并且使用 Hsf, Dubbo 等 RPC 框架将发布语言封装在最底层。这也是我将本条放在最后一个的原因。

总结

软件工程追求的终极目标就是 “高内聚，低耦合”，翻译成两个正面的指标就是内聚和解耦：

● 共享内核：内聚度最高，解耦最差
● ACL：内聚度最低，解耦最强

这张图恰恰反映了软件工程没有银弹的道理，通过梳理系统间关系，合理的控制系统的内聚与耦合程度，才是项目架构的难点所在。

ACL 被滥用的原因在于开发者将自己写的一小部分代码像“伊甸园”一样保护起来，这是比较简单的处理方式，但是如果要梳理如何和现有业务与系统结合，却要付出大量精力。这就导致系统过度“解耦”，以至于同一个团队维护的业务系统却给调用方一种支离破碎的感觉。

因此是否引入 ACL 要根据两个系统当前情况和未来规划决定，如果满足下面的一条到两条：

● 同一个团队维护
● 属于同一个业务
● 模型差别不大
● 短时间内目标相同，不需要完全独立发展

其中的一到两条。此时可以考虑暂时不引入 ACL，而是采用共享内核，或者客户-供应商来处理系统间关系。

但是这条定律也只能作为参考，还是需要结合现实中对于内聚与解耦的需求决定，毕竟软件工程中唯一的定律就是没有定律。