1.2 架构的定义（一）

什么是架构？上述提到的顶层设计、体系性结构设计、规划设计，如果我们用一个更加通用的、朴素的、专业化的、且辨识度更高的名词进行语言上的整合统一，不妨就叫架构设计。

在阐述架构设计的概念和内涵之前，我想我们不妨先耐住性子，追根溯源，思考下什么叫架构。

在言及架构的语境中，建筑行业提及较多，政府报告中出镜率也不低，此外，在信息通信行业中架构也几乎是家喻户晓。

建筑行业中，架构经常用来描述建筑物内部的空间结构以及空间联络，可以说是物理意义上的架构，往往是可见可体验的，因此对大众来讲更具体。

政府报告中往往说的较多的是顶层架构设计，往往针对某一行业某一方面所做出的一种宏观性、体系性、前瞻性的布局。譬如，国家级算力枢纽的顶层架构设计、国家级新基建顶层设计等。虽然内容很宏观，概念也很宏大，但化繁就简了之后，其实也无外乎结构和规范等相同的画面。

在信息通信领域，架构出现的密集性几乎是空前的，形形色色挂着架构头衔的岗位、工作往往缺乏统一的概念基础而让人眼花缭乱，不知所云。我们撇开那些似是而非的概念，信息通信领域的架构一般广为人所接受的，其一是岗位上的架构师，至于加上前端、后端等前缀和修饰，并没有改变本质，更多是细致化；其二是架构设计讲的是一种活动；最后就是架构设计针对的内容，如业务架构、应用架构、技术架构及数据架构。那么业务架构、应用架构、数据架构和技术架构抽象来看，设计的含义又是什么呢？其实还是结构以及连接。如果我们稍微发散一下就是聚类、定位、交互和内容范式。

我们不妨尝试给架构下一个定义，虽然只是一家之言，即架构是一个事物内部各个分部的逻辑结构，以及分部之间的连接关系。架构的核心要素有整体、分部、结构和连接。

整体，即架构对象。用建筑术语表示，好比是某个具体的建筑物，用 IT 系统的视角来看，整体可以是一个系统，一类数据，一连串技术。整体是架构设计的目标对象。所有的架构设计活动都是从认识整体开始的，对整体的理解越深刻，架构设计的脉络性就越强，手法自然也就更显高明和远见。

分部，把整体按照一定的逻辑进行切割和拆解，再经过抽象和聚类形成的局部或片段。分布的划分往往很具有挑战性，既是对经验的考验，又是对未来判断的体现。

结构，即分部之间的空间结构。划分了分部之后，如何合理得组织这些分部，规定各个分部的职责范围，上下游，类似军队的排兵布阵。既有经验和阅历的成分，也有一些哲学、理念和现实的影响。

连接，即分部之间的交互范式。有了分部和结构还远远不够，我们的目的是整体，是一个运转良好的整体，而不是一堆看上去匠心独运、结构清晰但分散的片段。因此，如何让各个分部在指定的结构下有效的互动，且有规可循，是不可缺失的重要一环。

不难发现，架构设计其实是整体与分部之间的分化、再连接的逻辑行为。

让我们再用具体的案例来进一步阐述上面的概念。

以业务架构为例。

业务架构的整体是一项业务。每一项业务都有明确的经营范围，清晰的履约流程，具体的营销策略。用架构的角度来看，那么它的分部可以是各项业务活动，如设计、研发、营销、售后、供应链、渠道等部分。它围绕的是内外的价值链而划分。

它的结构即使各个分布在价值链上的位置、半径、上下游。

它的连接就是各个分部的协同、互动，以及协同内容的标准规范。如营销部门传递什么内容给产品部门，又传递哪些信息给售后部门，售后部门需要在什么时候通过哪些途径反馈何种信息给营销部门，大家都是按照预先共识好的流程开展工作。

以应用架构为例。

应用架构的整体即整个系统的全部功能。以微信为例，他的整体即微信。

分部，如注册、好友、朋友圈、消息等。

结构，如何指定注册、好友、朋友圈、消息等各分部之间的逻辑结构。

连接，消息分发如何与好友交互？交互的形式、格式分别是什么？

正如莎士比亚所说的“一千个观众眼中有一千个哈姆雷特”，架构在不同的背景、经历、学识和阶段的人心中，也会有不同的理解。我们无法断言某个说法绝对正确，同样，也无法断言某个定义一定全错，虽然听起来有点故弄悬殊，但事实正是如此，因为我们每个人都好比是盲人，每个人心中的大象都可能是局部正确，但整体不够健全。因此，对于架构的理解，不要指望行业统一，但一定要有自己的理解。