分析模型的三个域

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

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

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

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

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

打开APP查看高清大图

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

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

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

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

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

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

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

打开APP查看高清大图

dns3个区域中，可读写的区域是非顶级域。根据查询相关公开信息，DNS的三个区域是顶级域（TLD）、非顶级域（Non-TLD）和反向域（ReverseDomain），可读写的区域是非顶级域，是一个用于存储域名和IP地址的数据库，可以被用户自定义，用于指定域名的IP地址，以及指定IP地址的域名，可以被用户自定义，用于指定域名的IP地址，以及指定IP地址的域名。

---