“三段三域法”应用架构模型

其木Zimmer 2022-01-13

展开全文

1、应用架构的关注点

作为常见的架构家族三兄弟，业务架构宏观外向，满口业务语言；技术架构务实内向，技术本位，讲究落地；而应用架构更像连接器，既具备不俗的业务理解力，又具备宽广的技术视野。

作为承前启后的关键角色，应用架构既要充分深入的理解业务架构的宏伟规划、长远布局和周边生态，又要细致研究业务之间的分合逻辑和交互特征，还要兼顾组织和人员，更要考虑技术成熟度、趋势和成本收益，此外，如何管控、运营，同时保证安全运行，也在思考之内。因此，应用架构本身属于一项复合型工作，左手牵着业务，右手连接技术。

那么作为粘合层的应用架构，到底关注什么内容呢？他的边界又在哪里呢？

A.全局识别。应用架构首要任务是理解业务架构，并识别其中显式或隐式的业务区块、内外部关联系统、相关领域对象、对象间的交互特征，同时还需要洞察未来一定周期内业务的走向。

B.部件分解。基于全局识别的知识，应用架构需要结合架构模式、业务耦合内聚关系、团队分布等进行分解，按照终端访问从前端到后台、业务亲缘性从紧到松的交叉维度，分解出若干个既独立又协作的“部件”，这个部件在不同的架构模式中，有不同的体现形式，譬如单体应用中的模块，微服务架构中的服务等。

C.互联协作。分解之后，如何连接起来完成业务呢？是请求应答模式，还是事件驱动，还是数据共享呢？

D.技术植入。上述三部，本质上是对业务架构中业务领域的拆解和联通，但是光有这些是不足够的。对于一个稳定运行并服务于大众客户的系统，访问控制如何实现呢？如何在充满各类攻击的恶劣网络环境中稳如磐石呢？如何感知系统运行状态呢？虽然业务架构不会告诉你这些内容，但是我们要明白，安全可靠、自动化和智能化是每一个系统的“在水伊人”，是底层语境。

2、“三段三域法”应用架构模型

既然应用架构关注内容如此广泛，那么有没有统一的参考思路，用相对统一的表现形式去呈现不同应用系统的应用架构，避免五花八门的出品带来的沟通障碍和解释成本呢？

或许没有标准的方案，但是并不妨碍我们进行尝试。

根据系统的不同，应用架构中需要体现的业务区块、关联系统、领域对象和架构模式也会不同。但是如果我们通过抽象屏蔽掉具体的业务概念，通过从前到后的“三段式”拆解手法和按照关注进行区域归类手段，或许可以构建出高层次的应用架构模型，本文尝试介绍“三段三域法”。

所谓“三段”，是指一个对象可以根据处理时序、职责范围等内在逻辑进行抽象，分为三段，譬如前段的展示渠道、中段的处理核心、后段的资源支撑。三段式是一个通用概念，可以用在整个系统的维度，又可以用在放大后的系统局部部件中。

所谓“三域”，是指根据关注焦点、技术要求、指导思维和工具箱的不同，将系统从逻辑上拆分为业务域、数据域和技术域三者。业务域关注如何通过拆分组合的艺术手笔和多因素综合权衡的决策理念来完成整个系统的功能搭建；数据域则关注数据的集成汇聚、过滤萃取、利用算法等手段洞察客户意图和市场逻辑以及数据资产编目和服务于业务；技术域则从技术维度出发，聚焦可靠、安全、运维、管控等目标，尝试在各个信息交互的边界进行技术手段的植入。

“三段三域法”应用架构模型图

首先，我们循着请求流向，来看“三段”。

在该模型中，我们我们假设每一个应用系统都有一个对外提供产品功能或服务能力的出口，我们称之为“数字化渠道”，它可以是面向内外不同群体的终端产品，譬如APP或者小程序，也可以是API，甚至是SDK。

其次是业务能力内核，包括请求接入、编排、持久化，是各类规则、流程、事务的集中营。

最后边的是支撑系统，可以是内部系统，也可以是外部系统，主要提供专业化的能力。

其次，从区域来看，每一个系统，基本都由业务、数据和技术三体组成（其实这也是另一个维度的“三段”）。

业务域关注是功能、流程、客户群体。又可以抽象划分为常规业务域，一般是企业的主营业务；创新业务域，一般是企业的增值类、开放式、生态类业务；支撑业务域，一般是偏向管控和支撑类的业务，譬如客服系统、工单系统等。最后一个可能出现的是共享业务域，涵盖各个类型业务的共享部分。每一个业务域之内的主体，我们统称为“部件”。