什么是架构？

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

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

关联到软件领域，木就是系统中的要素，我们将他们称之为架构要素。架构要素可以是子系统、模块、应用服务。

结构，是架构的产物。不同的软件系统会有不同的结构，这些结构是为解决不同场景而设计的。

连接，通过定义架构元素之间的接口和交互关系、集成机制，实现架构元素之间的连接。连接可以是分布式调用、进程间调用、组件之间的交互关系等。

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

画架构图的目的

架构图，是可视化的，是给人看的。所以，归根结底是为了交流理解。

对上：经常需要汇报，争取领导层的认同支持。

对己：借助多种视图来厘清思路。

对下：用不同视角来表达自己的想法，沟通交流。

架构图之间的关系

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

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

接下来我们将一一介绍这些架构图。

架构图的种类

业务架构

业务架构是对业务需求的提炼和抽象，使用一套方法论对产品（项目）所涉及需求的业务进行业务边界划分，简单地讲就是根据一套逻辑思路进行业务的拆分，开发软件必须满足业务需求，否则就是空中楼阁。软件系统在业务上的复杂度问题，可以从业务架构的角度切分工作交界面来解决。比如在做一个电商网站时，需要将商品类目、商品、订单、支付、退款等功能很清晰地划分出来，不要在业务架构中考虑用什么技术开发、并发量是否太大、选择什么样的硬件等等。

这里简单规划了电商系统的业务模块，对其根据业务架构的模块不断细化。对于软件开发而言，以业务架构为依托，架构师和开发者能比较清晰地看到系统的业务全貌，架构师能更方便地分析系统复杂度，分解业务逻辑，做好开发的分工，如图所示。

产品架构图

产品架构图需要将各业务的板块及支持板块细化出功能板块。还是以电商举例，账号模块有：登录、注册、找回密码等功能；商品模块有：商品上架、品类管理、相似推荐等功能；订单：......；物流：.....；每一个业务板块可以细拆出核心功能。

我们将电商的每个业务板块细化出功能模块，即可得到如下图的电商平台产品架构。

应用架构图

所谓的应用架构就是公司所有产品和系统的整体结构和布局。

还是以电商为例，我们画一下它的应用架构图。

技术架构图

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

技术架构解决的问题包括：纯技术层面的分层、开发框架的选择、开发语言的选择、涉及非功能性需求的技术选择。

这是是一个通用的公司技术架构图，不同的公司规模或者产品不同，最后的架构图可能会有出入，但是大部分都是通用的，这个图也算是有点规模的公司最终落地的技术形态了。

数据架构图

数据架构是对存储数据（资源）的架构，其设计原则和应用架构设计大同小异，在设计时需要考虑系统的业务场景，需要根据不同的业务场景对数据进行异构设计、数据库读写分离、分布式数据存储策略等。下图是电商系统中数据架构的一个概要。

画架构图这个事一般是公司的架构师做的，但有些公司没有专门的架构师，这些工作就需要产品经理做了。无论公司有没有架构师，对于产品经理而言，了解这些事情，对产品经理也是大有裨益的。