架构思维概述对于架构思维本身来说，它仍然是系统思维、结构化思维、程序化思维等多种思维模式的集合。既然架构的核心作用是在现实的业务世界和抽象的IT实现之间架起一座桥梁，那么架构思维的核心就是理解业务驱动的技术，为最终的业务服务。需要通过架构设计，真正做到业务与技术、需求与实现、软件与硬件、静态与动态、成本与收益的平衡。之前很多文章都提到，架构设计有两个重点，一是分解，二是集成。分解是最基本的。架构的重点是分治复杂的问题，同时保证分解后的部分仍然可以高内聚、松耦合，最终整合成一个完整的整体。分解的核心是定义的问题，所以架构还是要先了解需求。整合是以分解完成的动作。最终分解出来的组件或子系统可以通过适当的界面设计集成为一个完整的整体。分解只是为了加快开发速度，降低问题的复杂度。如果分解后的内容无法整合，那么分解就没有任何意义。分解+集成可以理解为架构的核心思维方式和方法。分解完成后，一个大系统被拆分成了很多小模块，或者一个小模块本身的实现被分成了多个步骤。然后要把分散的节点聚集起来，向上汇总，形成一个完整的架构。而形成这种结构的关键是分层思维。架构分层是谈架构绕不开的一点。通过架构分层，我们可以更全面地了解业务系统或功能实现。云平台三层架构：资源-平台-应用在规划大型架构时，我们经常会提到云计算标准的三层架构，即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接口就是服务层，最终的前端业务或者流程就是应用功能的实现。应用架构的分层回到单体应用的架构分层，说的最多的就是常说的三层架构模型。在软件架构中，经典的三层架构自上而下由用户界面层（UserInterfaceLayer）、业务逻辑层（BusinessLogicLayer）和数据访问层（DataAccessLayer）组成。在整个实现过程中，可能会增加一个独立的Facade层，或者一个独立的API接口服务提供者层，一个统一的DTO数据传输对象层等，但这些并不影响整体的三层逻辑结构。三层架构本身也完全对应一个业务功能的实现。在数据访问层处理数据的获取和持久化操作，在业务逻辑层处理业务规则，在界面表示层进行相应的前端呈现和用户交互。说到领域建模，也介绍了领域模型中的分层架构，具体如下：领域驱动设计在经典三层架构的基础上进一步改进，用户界面层和用户界面层之间的接口引入了业务逻辑层。一个新的层，应用层（ApplicationLayer）。同时，部分关卡的命名也发生了变化。将业务逻辑层更名为领域层自然是题意所在，而将数据访问层更名为基础设施层（InfrastructureLayer）突破了以往数据库管理系统的局限性，扩大了封装技术的复杂度。内容的基本水平。当然，还有一种将领域模型与传统三层架构思想相结合的技术架构如下：领域层和业务逻辑层领域建模的核心是领域模型，领域模型不再是一个领域模型。独立的数据库表或数据对象。相反，它是一个业务对象或域对象。因此，领域层是为领域对象设计和实现的，业务规则能力本身也是领域对象提供的能力接口。也就是说，业务规则本身也是领域对象公开的能力。传统业务逻辑层的实现往往是一个数据对象对应一个DAO、一个Service和一个Interface。在领域模型下，DAO可以分离，但是业务逻辑层应该更多的按照领域模型来组装聚合DAO层的能力。独立的应用层拆分在我最初的理解中，领域层提供领域模型和领域服务能力接口，而应用层更多的是将领域层的多个领域对象模型提供的服务能力进一步组装整理，然后暴露出来用于前端应用程序。说到应用层的概念，其实可以理解为前端应用中已有的通用能力的进一步下沉。也就是说，应用本身只是用户业务功能实现的承载者，但是这个功能可以通过各种前端呈现形式来实现，比如传统的CS桌面应用、BS应用，或者手机APP。在电子商务中，一个产品订单是一个独立的应用，用户可以在APP端完成，也可以在BS端完成，但无论在哪里完成，最终应用层提供的能力应该是一样的。例如，要完成一个产品订单，它需要同时交付并与底层订单、库存和支付服务协调。那么这个逻辑显然不适合同时在BS端应用和APP端应用重复编写和开发。那么这个内容应该在应用层实现。如果再回到微服务和中台架构，这种应用层的拆分就更有必要了，就是把常见的服务组合和组装逻辑通过应用层降下来。这种逻辑和协作不应该属于任何前端应用程序。Interfacelayerorinterfacelayer在开发具有聚合能力的中台微服务模块时，可以看到微服务模块本身是没有接口表现层的，所以微服务的顶层只是提供API接口的接口服务层.该API接口服务能力既可以提供给APP前端，也可以提供给BS端。分层软件技术架构软件技术架构构成，分层仍可采用软件三层分层模型，重点是清楚说明各层所用到的关键技术组件或技术服务能力。比如三层软件开发模型的技术架构，分层如下：如果是技术平台，类似于大数据平台，那么在构图的时候还是要先考虑分层，然后再解释详细介绍每一层的技术内容。比如对应一个大数据平台，包括大数据的采集、大数据的存储、大数据的处理、大数据的分析和应用，那么这个就是关键的分层，每一层采用的关键技术都可以基于这个来考虑分层。技术栈构成也可以参考技术架构构成模式。技术架构需要回答的重点是你在软件架构设计过程中会用到哪些关键技术，哪些开源产品或工具。它可以细化到特定的技术产品，或者只细化到产品类型。比如消息中间件，你可以细化为采用RabbitMQ，也可以只在技术架构上体现消息中间件的使用。技术架构和软件功能分层架构唯一的相似之处就是分层。技术架构在每一层中没有具体的业务功能点和实现内容，只有关键技术点的描述。单一的应用功能架构注意，应用功能架构完全是着眼于描述应用系统的功能，而不管采用什么三层技术架构来实现一个功能。因此，功能架构不应该体现数据层、逻辑层、技术点。那么如何对一个应用系统的功能进行分层呢？我们可以参照业务的层级分类，将业务划分为基础支撑层、执行层和决策管理层。这样基本的层次模式就出来了，基于这个方法可以完成一个功能架构组合。对于单体应用，一般没有云平台、PaaS平台这样的概念。但是单体应用的构建必须具备通用的技术支撑平台能力，比如自己的流程管理，自己的通用技术功能组件。因此，单体应用的构建也可以采用基础技术支撑层+应用层+门户层的方式组合。在应用层，根据具体的业务领域或业务阶段进一步细分。架构图的分层组成逻辑前面基本给出了不同类型架构图的核心分层逻辑。可以看到，在画架构图的时候，尽量不要把不同场景下的组合方式混在一起，否则会导致整体架构图。困惑。在绘制整体架构时，一般需要重点关注云三层架构和SOA三层架构的组成模式。在细化某个应用系统的时候，还是要区分是构建技术架构图还是功能架构图。两者的层级逻辑也大不相同，不能混用。架构图的构成逻辑要完成一个完整的架构图构成，可以拆分为两侧+中间。双方一般都有具体的标准规范，如安全管理、质量管理、技术标准规范、开发运维规范等。中间是分层建设需要考虑的重点。前面也提到了，中间部分重点提到了云计算和SOA架构的分层逻辑。一般来说，核心是资源层、平台层、应用层和门户层。对于应用层本身，可以考虑进一步拆分业务域，也可以按照价值链或业务生命周期拆分成多个阶段域进行描述。在云和SOA下，更强调平台+应用的构建模式。两者之间一般是服务层，通过SOA平台或API能力开放平台统一访问和发布服务，形成资源+服务+应用的完整松耦合架构。同时，一个完整的架构本身就是多视角的，表现为：功能架构往往可以被特定的用户和业务人员看到，而技术架构往往被团队内部的开发人员讨论和使用。针对资源和平台设计的架构图往往是运维工程师构建部署架构的重要参考。因此，不同维度的架构分层属性不能随意组合使用，导致架构图混乱。
