今天谈下架构设计中的分层思维和分层模型以及基于分层思维下的架构构图逻辑。

架构思维概述

在前面多篇文章已经提出，架构设计中有两个重点，一个是分解，一个是集成。

分解是最基础的，架构的重点就是要对复杂问题进行分而治之，同时保证分解后的各个部分还能够高内聚，松耦合，最终又集成为一个完整的整体。分解核心是定义问题，因此架构首先仍然需要理解清楚需求。

集成是配合分解完成的动作，最终分解完成的各个组件或子系统，通过合适的接口设计，最终还能够集成为一个完整的整体，分解仅仅是加速开发和降低问题复杂度，如果分解后的内容无法集成在一起，那么分解就没有任何意义。

分解+集成可以理解为架构最核心的思考方式和方法。

在分解完成后，一个大的系统已经拆分为了诸多的小模块，或者一个小模块实现本身又分为了多个步骤阶段。那么零散的节点必须向上汇集和归纳，形成一个完整的架构。

而这个架构的形成要给关键就是要又分层思维。架构分层是谈架构绝对绕不开的一个点，通过架构分层可以更好地全面理解业务系统或功能实现。

云平台三层架构：资源-平台-应用

在规划大架构的时候，常会参考云计算的标准三层架构，即IaaS层，PaaS层，SaaS层。对于IaaS层重点是IT基础设施和虚拟化；PaaS层重点是构建平台层服务能力；而对于SaaS层则是具体的应用。

对于资源层从物理资源，再到虚拟化逻辑资源，从虚拟机到现在更加轻量的容器资源。而对于平台层原来只谈技术平台，但是当前又进一步拆分出业务平台，也可以理解成当前说得比较多的中台层。

同时在平台层和应用层之间增加了服务层，实现资源和服务的解耦。

如果涉及到物联网类应用，一般还会在底层增加网络层和感知层，比如一个智慧城市标准平台和应用的架构图类似如下：

在平台+应用构建模式下，一般在平台和应用之间还会有一个单独的服务层来实现接口服务对外的能力开放。资源+服务+应用也是我们常说的SOA分层架构模式，因此对于服务层也可以单独拆分出来作为一个小分层。

在构建一个完整的总体架构的时候，实际上没有数据层这个概念，数据层是在表达单个应用系统的分层架构实现的时候才会出现的内容。

在总架构图里面把类似结构化数据库，非结构化数据等全部列出单独一层这个也不对，这个应该是在技术架构里面体现。

还有一种是单独分出一个数据层，将大的公共基础数据列出，比如上面谈的智慧城市架构图。如果这些基础数据存在共性能力朝上提供，那么可以归纳到PaaS平台层，在PaaS平台层单独分出一个数据平台域来进行体现。

在构建整体架构的时候可以单独出一个能力开放平台或服务层，但是不用体现具体有哪些业务服务能力。因为单独出业务服务能力本质已经属于应用层内容，即应用又细化拆分为了业务中台和前台应用，中间衔接的服务。我们可以参考网上的另外一个构图，如下：

这个构图既不像云平台中的分层架构，也不像应用功能实现中的分层架构。实际可以看到如果体现单独的支撑层，支撑层已经类似现在经常说到的业务中台和能力提供。

SOA分层：组件-服务-流程

对于SOA架构分层，重点要体现的就是服务，对于组件本身是属于逻辑资源层的概念，而对于服务则是资源对外暴露的能力抽象。

SOA架构分层重点就是要体现出独立的服务层，注意不是画服务总线，这里可以单独画出具体提供哪些业务服务能力，技术服务能力。在采用SOA架构进行开发的时候，整体业务系统拆分为4个组件，10类服务域，5类流程，那么在构建的时候重点就是将上述组件，服务域和流程类体现出来。对于参考SOA架构来进行的构图，参考如下:

这里的数据层最好改为标准的组件层，更加贴近SOA架构模型。在图中的服务层已经可以看到一个个独立的API服务接口。如果服务接口数据大，一般只会划分到服务域，比如用户中心服务，采购类服务等。在这种方式下构图参考如下:

在上图中结合了云和SOA两种架构融合在一起，对于上图中的服务层实际可以理解为组件资源层和服务接口层的融合。更好的构图方式应该是拆分为标准的中台资源层-服务层-应用层。

云和SOA架构融合

注意对于云分层架构重点强调的是基础设施，平台和应用三层架构。而对于SOA架构强调的是资源，服务和应用三层。而对于对于传统的应用系统的构建一般又包括了IT基础设施，技术平台，数据库，中间件和应用。再到应用系统本身的分层架构可能又是标准的三层架构模式等。

这些架构分层方法都帮助我们进一步融合分层架构模式。

架构分层有很多方法，包括基础设施层，平台层，组件层，支撑层，服务层，应用层，数据层，展现层等。多种分发导致分层模型反而出现歧义和模糊。

在这里我们从技术架构和应用架构两个层面来谈，技术架构沿用云计算的三层模型；而对于应用架构则采用eTOM模型标准的资源，服务，应用三层模型。那么两种分层架构模型的融合则是一个完整的云和SOA融合的分层架构模型。

即云计算的三层中，每一个层次本身又可以进一步拆分为资源，服务和应用三层。

拿IaaS层来说，最底层的物理资源虚拟机等是属于资源层内容，通过IaaS层资源能力提供API接口作为技术服务进行能力开放，即是服务层；最终基于资源能力，构建了一个公有云的面向公众的运营服务平台，本身又属于应用层的内容。而对于SaaS层，则底层的业务组件是资源，抽象的API接口是服务层，最终的前端业务或流程是应用功能实现。

应用架构分层

回到单个应用的架构分层，谈得最多的就是常说的三层架构模式。在软件架构中，经典三层架构自顶向下由用户界面层（User Interface Layer）、业务逻辑层（Business Logic Layer）与数据访问层（Data Access Layer）组成。

在整个实现过程中，可能还会增加独立的Facade层，或独立的API接口服务提供层，统一的DTO数据传输对象层等，但是这些都不影响整体的三层逻辑结构。

三层架构本身也和一个业务功能实现的完整对应，在数据访问层处理数据获取和持久化操作，在业务逻辑层对业务规则进行处理，在界面展现层进行相应的前端展现和用户交互。而谈到领域建模的时候，又引入了领域模型中的分层架构，如下：

领域驱动设计在经典三层架构的基础上做了进一步改良，在用户界面层与业务逻辑层之间引入了新的一层，即应用层（Application Layer）。同时，一些层次的命名也发生了变化。将业务逻辑层更名为领域层自然是题中应有之义，而将数据访问层更名为基础设施层（Infrastructure Layer），则突破了之前数据库管理系统的限制，扩大了这个负责封装技术复杂度的基础层次的内涵。

当然，也有融合了领域模型和传统三架构思路后的技术架构如下：

在领域建模的一个核心是领域模型，领域模型不再是一个个独立的数据库表或数据对象，而是一个业务对象或领域对象。因此领域层是面向领域对象而设计实现，而业务规则能力本身也是属于领域对象对外提供的能力接口。即业务规则本身也是领域对象暴露的能力。

传统业务逻辑层实现往往是一个数据对象对应一个DAO，一个Service和一个Interface。而领域模型下DAO可以是分开的，但是Service逻辑层往往则更多应该按领域模型思路对DAO层的能力进行组装和聚合。

在我原来理解里面，领域层提供领域模型和领域服务能力接口，而应用层更多的是对领域层多个领域对象模型提供的服务能力进一步进行组装和编排，然后再暴露给前端应用。

谈到应用层的概念，实际上可以理解为前端应用中存在的共性能力的进一步下沉。即应用本身只是用户业务功能实现的承载，但是这个功能的实现可以通过多种前端展现形式，比如传统的CS桌面应用，BS应用，或手机端APP。

在电商里面，一个商品订购就是一个独立的应用，用户可以在APP完成，也可以在BS端完成，但是不论在哪里完成最终应用层提供的能力都应该一样。比如完成一个商品订购需要同时和底层的订单，库存，支付多个服务进行交付和协同。那么这个逻辑显然不适合同时在BS端应用和APP端应用中进行重复编写和开发。那么这个内容就应该在应用层实现。

如果回到微服务和中台架构下，这个应用层拆分更加必要，即通过应用层来下沉共性的服务组合和组装逻辑，这个逻辑和协同不应该属于任何一个前端应用。

在开发一个聚合能力的中台微服务模块的时候，可以看到这个微服务模块本身并没有界面展现层，那么该微服务的最上层仅仅是提供API接口的接口服务层。

该API接口服务能力既可以提供给APP前端，也可以提供给BS端使用。

软件技术架构分层

软件技术架构构图，分层仍然可以沿用软件三层分层模型，重点是说明清楚各层用到的关键技术组件或技术服务能力。比如软件开发三层模型的技术架构分层如下：

如果本身就是一个技术平台，类似大数据平台，那么我们在整体构图的时候仍然需要考虑先进行分层，再详细说明每层里面的技术内容。

比如对应一个大数据平台，包括了大数据采集，大数据存储，大数据处理，大数据分析和应用，那么这个就是关键的分层，可以基于这个分层再来考虑各层采用的关键技术。

对于技术栈构图基本也可以参考技术架构构图模式进行。

技术架构重点需要回答的就是你在进行软件架构设计过程中，究竟会用到哪些关键技术，哪些开源产品或工具等。可以细化到具体的技术产品，也可以仅细化到产品类型。

比如消息中间件，你可以细化到采用RabbitMQ，也可以在技术架构中只体现采用消息中间件。

技术架构和软件功能分层架构唯一相同的就是分层，技术架构在各个分层里面都没有具体的业务功能点和实现内容，仅仅是关键技术点说明。

单个应用功能架构

注意应用功能架构完全是重点描述应用系统具备哪些功能，一个功能究竟是采用什么三层技术架构实现并不用关心。因此功能架构不应该体现数据层，逻辑层，技术点这些内容。

那么对于一个应用系统的功能如何分层？

我们可以参考业务分层分类，将业务分为基础支撑层，执行层，决策管理层。这样基本的分层模式就出来了，基于该方式可以完成一个功能架构构图。

对于单个应用来说一般不会自身有云平台，PaaS平台这类概念。但是单个应用构建一定存在共性技术支撑平台能力，比如有自己的流程管理，各自共性技术功能组件等。因此单应用构建还可以采用基础技术支撑层+应用层+门户层的方式进行构图。

在应用层再按具体的业务域或业务阶段进行进一步细分。

架构图的分层构图逻辑

在前面基本给出了不同类型的架构图的核心分层逻辑，可以看到在画架构图的时候尽量不要混合使用不同场景下的构图方式，否则就导致整体架构图混乱。

在画整体架构的时候一般需要重点参考云三层架构，SOA三层架构的构图模式进行构图。而在细化到某一个应用系统的时候，仍然还需要分清是构建技术架构图还是功能架构图，两者本身的分层逻辑也存在很大的差别而不能混用。

要完成一个完整的架构图构图，可以先拆分为两边+中间。两边一般是放具体的标准，规范等，比如安全管理，质量管理，技术标准规范，开发运维规范等。

中间即是重点需要考虑进行分层构建的地方。

在前面也谈到了中间部分重点参考云计算和SOA的架构分层逻辑。一般来说核心的还是资源层，平台层，应用层，门户层。而对于应用层本身又可以考虑业务域进一步拆分，或者根据价值链或业务生命周期拆分为多个阶段域再展开描述。

在云和SOA下，更加强调平台+应用构建模式。

而两者之间一般是服务层，通过SOA平台或API能力开放平台来统一接入和发布服务，以形成一个完整的资源+服务+应用的松耦合架构。同时一个完整的架构本身就是多视角的，如下：

功能架构往往可以给具体用户和业务人员看，而对于技术架构往往更多是内部团队开发人员研讨使用。而设计到资源和平台的架构图往往又是运维工程人员进行部署架构搭建的重要参考。因此不同维度的架构分层属性本身不能随意融合使用，而导致架构图混乱。

-- End --