1、应用架构的关注点



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





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



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



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



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



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



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



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



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



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



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



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



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





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



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



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



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



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



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



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





业务域



数据域关注是数据的全生命周期，从集成到加工，再到数据服务以及提领整个三段式处理过程的数据编目。



技术域关注的是技术植入，包括如何构建工具和方法论体系、实现部件间高效无障碍联通、用于实现灰度黑白名单以及海内外请求调度的访问控制、为抵抗攻击和数据隐私的安全护航以及感知整个系统运行状态的度量数据。技术域的不同部分穿插分布在各个部件之间。





当然，如果我们进一步放大，在业务域的各个子类中，仍然跟随请求流向，也可以细分为开放接入、业务编排和持久化三部分。同时，每一个部件之内，无论这个部件的运行时形态是单体架构模式中的一个类库、还是一个微服务架构中的独立进程的服务，也多可以按照业务、数据和技术三方进行编织。



3、“三段三域法”应用架构模型的示例



当然在不同的架构模式中，按照“三段三域法”落地的应用架构会有局部的不同，其中差异最大的还是技术域的单调或丰富，但是总体上会保持高度相似。



基于微服务架构的“三段三域法”应用架构。





基于单体架构的“三段三域法”应用架构。





4、总结陈词

抽象来说“三段三域法”其实是一个二维联合抽象的过程，而且是一个可以递归的过程。随着我们对“三段”和“三域”的低维度细化和具象填充，理论上我们可以得到从整个企业应用集，到单个系统，再到具体部件的应用架构图景，而且他们会有相同的表现形式、涵盖内容和思维抽象，这不正是当前我们所需要的吗？