业务架构图、产品架构图、应用架构图、技术架构图

什么是架构

在百度百科中的定义是：架构，又名软件架构，是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。

在维基百科中的定义是：软件体系结构是指软件系统的基本结构，创建此类结构的规则以及这些结构的文档。需要这些结构来推断软件系统。每个结构包括软件元素，它们之间的关系，元素和关系的属性，以及每个元素的引入和配置的基本原理。软件系统的体系结构是一种隐喻，类似于建筑物的体系结构。

从百科中我们提炼出一句话，“架构是一种整体与局部关系的抽象描述”。这句话还是稍显抽象，不太容易理解。换个角度，按照中文的字面理解，对“架构“两个字进行拆解，就会发现很有意思含义。

架构从字面意思上，是源于古代的建筑术语。把架构拆分成两个字“架”和“构”。“架”就是“加”和“木”的结合，把木头加起来、连接起来就是架。“构”就是结构的意思。所以，“架构”就是把“木“按照一定的结构连接起来。

下图为古代的木质建筑的结构图：

对应到软件架构，这里面的“木”代表什么，软件架构中的“结构”是什么，这些软件系统的“木”又是如何连接的？

• 关联到软件领域，木就是系统中的要素，我们将他们称之为架构要素。架构要素可以是子系统、模块、应用服务。
• 结构，是架构的产物。不同的软件系统会有不同的结构，这些结构是为解决不同场景而设计的。
• 连接，通过定义架构元素之间的接口和交互关系、集成机制，实现架构元素之间的连接。连接可以是分布式调用、进程间调用、组件之间的交互关系等。

总结一下架构的本质，即 “架构 = 要素 + 结构 + 连接”，将系统要素按照特定结构进行连接交互。

架构域的分类

架构域包括：业务架构、数据架构、产品架构、应用架构、技术架构等等。仁者见仁智者见智吧。

首先需要熟悉业务，形成业务架构，根据业务架构，做出相应的数据架构和应用架构，最后通过技术架构落地实施。

业务架构是战略，应用架构是承上启下，一方面承接业务架构的落地，另一方面影响技术架构的选型。

如何针对当前需求，选择合适的架构，如何面向未来，保证架构平滑过渡，这个是软件开发者，特别是架构师，都需要深入思考的问题。

业务架构图

关于业务架构，简单的说就是“企业希望从这个产品身上得到什么”，以及“用户想从产品身上得到什么”，比如电商平台这种战略性目标是显而易见的，用户买到想要的东西，企业卖出可以赚钱的商品。

为了实现这一目标，我们还必须弄清楚那些用户，能够通过什么渠道达成他们的目标，甚至还可能会有其他的目标。也就意味着产品端必须清晰的规划出一个完整的业务互动的过程，搞清楚一个产品涉及到的各种不同的角色，他们所期望的目标，以及他们的需要完成的业务动作，从而为产品设计打下基础。

客户的期望才是产品的真正价值。如何实现客户的期望则是产品经理的价值。

比如音乐类产品的业务大致包括了内容版权的生产、管理、消费，涉及到的就是用户如何消费内容，版权方如何产生内容，以及平台方如何基于内容进行的运营等，这个过程用一个图的表达，可以是这样的：

这种构建的方式，就是“以什么业务作为驱动”的设计方法，它考虑的是整个业务之间的互相协作来达成整体业务发展的问题。

换言之，“业务架构”考虑的是 如何为用户提供价值，以及企业可以通过什么方式来实现盈利的问题，强调的是我们能为用户提供什么，为了实现这一目标，我们需要做什么。

用这个思路来看新浪微博，其在营收业务层面，新浪微博主要依靠流量变现业务，比如广告业务等；在用户增长业务方面，微博主要的思路就是通过扶持KOL来产生内容和社交关系，从而做大垂直领域的流量。

基本上微博就是以社交为支撑，发力垂直业务来增加用户活跃，带来广告的变现。在此基础上的用户画像和社交关系，都是为了推动精准广告收入的提高。

用这个思路来看O2O平台，它涉及的用户既可以是终端用户，也可以是企业用户如电器卖场，作为连接用户和服务用户的“实体”则有坐席、门店和工程师，整个平台基于用户的服务请求形成的业务订单实现整个平台的业务流程。

ps，实际上业务架构图的表达方式并无定式，关键是如何清晰的表达整个模型是如何有效的开展业务，并在此基础上，能够进一步分解出产品的架构。

通过整个业务的架构，我们能够清晰的厘清整个平台的用户对象，业务关系，也就确定了整个产品的业务边界范围，确定了整个团队内的业务语言，所有的产品功能都基于两端（用户端和服务端）的业务价值来展开，从而避免了很多不必要的系统开支和过度设计。

产品架构

基础的产品框架脱胎于业务流程，但相比业务流程，更加注重产品功能的枚举、功能模块之间的分界。

当我们打开一个系统，我们会看到一个精美的页面，一些丰富的信息、导航。这些东西会引导我们去使用这个系统。这些东西就是这个系统的组成部分，就是这个系统的功能模块。产品架构，就是将这些不同用途的功能模块围绕特定的业务目标进行分类整合。

功能模块是用户能够完成一个操作的最小粒度的完整功能。比如一个展示可购买商品的列表页、一个修改用户密码的功能。在功能模块设计过程中，需要确保用户能通过一个功能模块完整的完成一项工作，而不是半个工作。

产品架构中，功能模块是根据其相互之间的关系来组织的。一个产品中不同的功能模块之间的关系分直接关系和间接关系。只有直接关系的功能模块才会被组织到一起，形成一个子系统。那些存在间接关系的模块，会在不同的层级通过直接关系的模块产生联系。

当具有直接关系的功能模块组合成一个子系统后，解决相同问题域的子系统就形成一个功能层级。功能层级按照接近用户实操的距离程度进行从上到下，或者从左至右的划分，这就形成了产品架构的分层。

如果把业务架构比作房子的地基，那产品架构就是房子的承重墙了，决定了产品的整体方向的结构。

以O2O平台为例，其业务主要是为了解决用户的“设备配送”、“设备安装”、“设备维修”三大类型，涉及的业务对象包括终端用户（发起服务请求）、门店（响应用户的服务请求）、工程师（履约服务工单）。

为了解决这一业务需求，整个平台需要完成三类服务实体（用户、门店、工程师）围绕“服务工单”的业务流转过程，我们可以用一个图来表达这种关系。

（ps，此文为简化版，后续再另文再详细阐述如何构建整个产品架构。）

这个图，我们能从上往下看用户发起请求后的一系列动作过程，也可以从下往上看，为了支撑用户的服务请求所需要构建的一系列服务。

从上图可以也可以得出一个结论，产品架构可以指导产品经理思考如何解决用户的问题，如何满足用户的期望。 作为产品的指南，“产品架构”解决的是如下三个问题：

• 产品方向。按照产品架构图的结构和路径，产品的RoadMap也就可以被清晰的拆解出来，同时它还能指导技术架构的选型，比如业务的容量，扩展性等等，为未来的产品发展指明了方向。
• 产品边界。不做什么，很多时候更为重要，明确一个产品的基本边界，可以让这个产品少走很多弯路，降低很多的风险和不必要的成本。这对于创业团队来说，有些时候非常关键。
• 产品路径。产品架构设计了各个功能模块的业务范围，针对每个功能的内外关系有清晰完整的定义。当一个产品的架构被确定后，也就确定了产品的迭代周内的范围，并且能够帮助上下游清晰的理解产品的结构、功能和复杂度。

从其解决的问题来看，我们也能很清晰的了解，一个好的产品架构图的基本要求：

• 功能经过抽象，做到标准化、互相独立
• 清晰的功能边界，架构分层明确
• 具备迭代优化的能力

应用架构图

应用架构是要说明产品架构分哪些应用系统，应用系统间是如何集成的。这就是应用架构和应用集成架构。

产品架构在业务架构的基础上，按照解决的业务问题域，划分出不同的功能模块，再根据功能模块间的关系，组合成子系统。应用架构在产品架构的基础上考虑两个事情：第一、考虑的是子系统间的关系。第二、考虑将可复用的组件或模块进行下沉，沉淀到平台层，为业务组件提供统一的支撑。

应用架构在规划时，需要遵循以下几个原则：

• 简单性：体现在应用架构是否有清晰、明确的层次划分，各应用系统之间的连接关系是否简单明确，系统之间的耦合程度低。
• 灵活性：体现在应用架构适应业务的快速变化，不仅要求在快速增加新应用时保持现有应用架构的稳定性，还要在适应业务变化的同时主动促进业务变革。
• 整合性：通过应用系统之间的解耦和组合，以统一的方式对外提供一致的服务接口，从而实现应用系统之间的共享和协作。

应用架构起到承上启下的作用：一方面承接业务架构的落地，另外一方面影响技术选型。

比较常用的应用架构类型包括：单体式、分布式、SOA架构。

分布式应用架构中，不同应用是独立的，应用内部高内聚，应用之间松耦合，可以灵活的进行分布式部署。同时缺点也比较明显，那就是不同应用之间通信连接都需要额外的工作量，同时整个架构设计变得复杂维护起来成本必然增加。

技术架构图

到技术这一层整个系统的设计已经比较清晰了，尽管技术架构图涉及的技术模型一般都比较多。但经过拆解，分组，已经非常直观了，我们可以把技术架构图简单理解为具体的装修设计图，剩下的就是靠技术人员分批分模块来慢慢实现了。

下面引用一张美团的系统架构图，这只是美团业务体系的一个缩影。从图里面我们可以了解到美团的业务极其复杂，使用的技术也非常多。

应用架构本身只关心需要哪些应用系统，哪些平台来满足业务目标的需求，而不会关心在整个构建过程中你需要使用哪些技术。技术架构是应接应用架构的技术需求，并根据识别的技术需求，进行技术选型，把各个关键技术和技术之间的关系描述清楚。

技术架构解决的问题包括：如何进行纯技术层面的分层、开发框架的选择、开发语言的选择、涉及非功能性需求的技术选择。由于应用架构体系是分层的，那么对于的技术架构体系自然也是分层的。大的分层有微服务架构分层模型，小的分层则是单个应用的技术分层框架。大的技术体系考虑清楚后，剩下的问题就是根据实际业务场景来选择具体的技术点。各个技术点的分析、方案选择，最终形成关键技术清单，关键技术清单考虑应用架构本身的分层逻辑，最终形成一个完成的技术架构图。

总之，技术架构是将产品需求转变为技术实现的过程。