系统结构的仪式感

什么是仪式感？

仪式感是人们表达内心情感的最直接的方式。仪式感可以提醒我们，生活不止眼前的苟且，还有诗和远方。仪式感未必是一些具体的、物质的行为，更多是一种人生活的态度。

为什么说系统结构要有仪式感呢？

系统结构是技术人员平日关注和打交道最多的东西，我们所有写的代码、消化的需求最终都会落到工程结构里面。

一个系统的工程结构，代表了系统负责人的态度，是内心对于这个系统所承接业务的技术实现的态度。

所以基于这个系统结构之上的所有代码组织与业务组织需要有仪式感。

如果没有仪式感，系统也就没有了态度。一个没有态度的系统势必是混乱的，像一个人一样，没有了底线和原则，时刻处在混乱之中。最终的表现就是，系统腐化，幸福度降低，稳定性差，扩展性差。

如何建立起系统结构的仪式感呢？

要回答这个问题，首先要想到这个系统将来的样子，也就是他的理想态。

理想态体现了系统的定位、容错性与扩展性，是站在未来的角度思考，思考系统变大之后如何应对外部对于他新的要求。

• 外部环境变了，他应该如何低成本的消化掉变化。

• 他是否可以自己消化，还是需要上下游一起配合。

• 他是否积累了正确且有价值的东西，在未来某一天把这些融合在一起即可，而不是不断推到重来。
  

简单来说，就是系统是否想好了他未来的样子，在未来到来的时候，他是否可以低成本的变成他想要的样子。

看个例子。

首先想到的仪式感是分离原则，一个承载业务需求的工程往往是包含业务逻辑和技术逻辑。所以首先想到的是将核心业务领域与技术功能分离开，类似于六边形架构或洋葱架构：

所以一个系统结构首先要有区分业务逻辑与技术逻辑的价值观。

那怎么体现在工程结构上呢？

一个系统维度的工程结构可以是这样的：

API层目的是将系统的业务能力暴露出去，他的扩展性需求来源于现有的rest api数据透传。

但需要考虑到一套api使用到原生app、H5、IOT设备等场景下。不同设备有不同的鉴权要求，不同的防刷、鉴权机制，这些扩展性要在现在的设计中有所体现，也就是塑造其价值观。

应用层解决是真正将业务需求消化到技术模型，理论上产品提的业务需求在这一层就会被消化掉，而不是继续透传到下面的领域层与数据层。我见过一些同学实现产品业务需求，从api到service到dao完全感知，这样的规则实现太刚性了，也是脆弱的。

扩展性要求是，不同产品、不同业务线、不同品类的个性化需求是否可以在这一层简单的再组合就可以实现，而不是牵一发动全身，大动干戈。所以一些流程编排、规则引擎、策略配置都是作用在这个地方，目的是低成本复用到存量的原子功能，编排出新的业务能力，实现产品的个性化需求。

领域层更多是给系统架构师及业务架构师看的，这部分不太受产品日常需求迭代的影响，更多体现的是系统负责人、架构师对于业务的抽象理解。

扩展性体现在对系统承接业务本质的抽象与沉淀，比如订单领域对于实物电商、虚拟电商在本质层面上有什么异同。支付系统对于线上支付、到家支付本质上有什么区别。技术挑战是对业务的抽象与建模。

数据层的主要职责是对于有状态持久化数据的存取，业务概念较少，更多需要考量的是不同存储设施的适配，比如关系数据库、nosql、newsql、es等，同时解决高可用、数据可靠性等问题即可。

防腐层，很多情况下并不存在一个这样的防腐层，可能是个适配层，但需要具备这样一个概念。

理论上每个系统都是有他的核心领域的，不同领域衔接在一起，往往是通过api或者mq通信实现的，为降低外部领域概念及数据结构对于系统核心领域概念的侵入，需要建立防腐层。他就像一个保安，把外部领域概念做结构化处理，才会给到系统的核心流程和逻辑之上，脏活累活在防腐层就搞定了。

系统有了自己的价值观与结构之后，我们再看下如何处理和外部系统的关系。

看个例子。

流程1、2、3可以看做是我们自己系统的核心流程，但在某一个流程需要借助于外部系统的规则做一些事情，而规则是由一个配置平台配置的规则集合产生的，这个系统间边界应该如何处理呢？

我们知道，一个系统的出现是为了解决某个核心问题，这个核心问题我们就可以看做是这个系统的定位与边界。

我们可以将上面的交互变成下面这个样子：

绿色部分解决的核心问题是核心流程的内聚，而黄色部分是规则的内聚。

这样的好处是绿色部分不感知规则细节，他只需要知道在哪个流程和规则产生关系就行了。

而黄色规则部分内聚规则细节，规则集可能很复杂，但需要把复杂度和规则优先级处理自闭环，防止负责度外溢，规则的驱动可能是在线计算、离线计算、外部能力的聚合。

如果绿色部分也需要感知规则，两者的边界就不清晰，后续的演进过程中少不了双方沟通的耗时。

合理的抽象是个硬功夫，不是每个人都可以做好抽象的，但本质还是高内聚低耦合，也是架构师和普通工程师之间的差别，好的抽象背后是对于业务本质的理解，比如规则定义这个本质决定了这个边界的划分。

很多同学可能会走到另一个极端，就是系统没那么复杂是否也需要建立上面的分层结构呢？

答案是否。

刚工作时大家刚刚理解三层架构，我看过一个人写了一个服务是三层架构，后来基于这个服务封装了一个open api层，又是个三层架构，所以简单的open api开发被设计成了6层。

但价值观和仪式感是要有的，分层和结构可以在头脑中，目的是应对未来的扩展性要求，尽管他可能还是长这个样子：