View on GitHub

业务逻辑拆分模式

https://autonomy.design

相加的关系

显然我们可以把业务逻辑分解成如下的多个Git仓库

Composition-1

这些一次性的Git仓库会相加到一起,就构成了完整的业务逻辑。

相乘的关系

然后我们会意识到,有一些重复的模式。 比如说这后台的表单都长得差不多啊,我们把表单的校验和错误回显封装个UI组件吧。 然后所有的后台表单都必须复用这个UI组件。 这样为了保障实现的一致性,就引入了相乘的关系

Composition-2

我们可以完全没有相乘的组合关系,而完全依赖相加来组合。但是相乘的组合关系通过只需要维护一份,使得一致性可以更好。从实现技术上来说,相乘的关系可能是运行时加载 Library 复用其函数,也可能是编译时的模板展开,代码生成。与”相加的关系”的主要区别是被复用多次,而不是用什么形式被调用。

一致性

假设我们把业务拆分成了一堆 Git 仓库,它们之间构成如下的依赖关系

Composition-3

在整个依赖关系树上面,我们可以画一根线。线之上的 Git 仓库定位就是一次性的,通过“相加”组合满足特定的业务需求。 通俗而言我们会称之为为“业务”。 对于业务我们仅仅要求 Autonomy 和 Feedback 的指标。

线之下的 Git 仓库定位是“保障整体的一致性”,是“相乘”的组合关系。 通俗而言我们会称之为“基础设施”。 除了要求 Autonomy 和 Feedback,还额外增加了 Consistency 的度量指标。 这些 Consistency 指标的主要目的就是防止过度抽象,什么都想“可复用”,导致 Autonomy 受损。 可以说这些 Consistency 指标实际上是度量了“可复用性的质量”。

实际上这些“基础设施”,与编程语言,操作系统,物理硬件能有多少区别呢? 区别仅仅是“开源社区共识”,还是“公司部门范围内的共识”罢了。 有野心一点的公司,或者业务模式内在一致性比较高的公司,大可以发明自己的领域特定语言(Domain Specific Language)嘛。 只要这个发明出来的 DSL 不是只适用于一两个地方,能够通过 Consistency 指标的检验,那就是有价值的。