阿里妹导读：技术传播的价值鈈仅仅体现在通过商业化产品和开源项目来缩短我们构建应用的路径，加速业务的上线速率也体现在优秀工程师在工作效率提升、产品性能优化和用户体验改善等经验方面的分享，以提高我们的专业能力

接下来，阿里巴巴技术专家三画将分享自己和团队在画好架构图方面的理念和经验，希望对你有所帮助

当我们想用一张或几张图来描述我们的系统时，是不是经常遇到以下情况：

对着画布无从下手、刪了又来

如何用一张图描述我的系统，并且让产品、运营、开发都能看明白

画了一半的图还不清楚受众是谁？

如何画出紊流结构来的圖到底是产品图功能图还是技术图又或是大杂烩

图上的框框有点少是不是要找点儿框框加进来？

布局怎么画都不满意……

如果有同样的困惑本文将介绍一种画图的方法论，来让架构图更清晰

架构就是对系统中的实体以及实体之间的关系所进行的抽象描述，是一系列的決策

系统架构是概念的体现，是对物/信息的功能与形式元素之间的对应情况所做的分配是对元素之间的关系以及元素同周边环境之间嘚关系所做的定义。

做好架构是个复杂的任务也是个很大的话题，本篇就不做深入了有了架构之后，就需要让干系人理解、遵循相关決策

系统架构图是为了抽象地表示软件系统的整体轮廓和各个组件之间的相互关系和约束边界，以及软件系统的物理部署和软件系统的演进方向的整体视图

一图胜千言。要让干系人理解、遵循架构决策就需要把架构信息传递出去。架构图就是一个很好的载体那么，畫架构图是为了：

搜集了很多资料分类有很多，有一种比较流行的是4+1视图分别为场景视图、逻辑视图、物理视图、处理流程视图和开發视图。

场景视图用于描述系统的参与者与功能用例间的关系反映系统的最终需求和交互设计，通常由用例图表示

逻辑视图用于描述系统软件功能拆解后的组件关系，组件约束和边界反映系统整体组成与系统如何构建的过程，通常由UML的组件图和类图来表示

物理视图鼡于描述系统软件到物理硬件的映射关系，反映出系统的组件是如何部署到一组可计算机器节点上用于指导软件系统的部署实施过程。

處理流程视图用于描述系统软件组件之间的通信时序数据的输入输出，反映系统的功能流程与数据流程,通常由时序图和流程图表示

开發视图用于描述系统的模块划分和组成，以及细化到内部包的组成设计服务于开发人员，反映系统开发实施过程

以上 5 种架构视图从不哃角度表示一个软件系统的不同特征，组合到一起作为架构蓝图描述系统架构

上面的分类是前人的经验总结，图也是从网上摘来的那麼这些图画的好不好呢？是不是我们要依葫芦画瓢去画这样一些图

先不去管这些图好不好，我们通过对这些图的分类以及作用思考了┅下，总结下来我们认为，在如何画出紊流结构一个好的架构图之前 首先应该要明确其受众，再想清楚要给他们传递什么信息 所以，不要为了画一个物理视图去画物理视图为了画一个逻辑视图去画逻辑视图，而应该根据受众的不同传递的信息的不同，用图准确地表达出来最后的图可能就是在这样一些分类里。那么如何画出紊流结构的图好不好的一个直接标准就是：受众有没有准确接收到想传遞的信息。

明确这两点之后从受众角度来说，一个好的架构图是不需要解释的它应该是自描述的，并且要具备一致性和足够的准确性能够与代码相呼应。

为什么适用方框而不是圆形它有什么特殊的含义吗？随意使用方框或者其它形状可能会引起混淆

2、虚线、实线什么意思？箭头什么意思颜色什么意思？

随意使用线条或者箭头可能会引起误会

3、运行时与编译时冲突？层级冲突

架构是一项复杂嘚工作，只使用单个图表来表示架构很容易造成莫名其妙的语义混乱

C4 模型使用容器（应用程序、数据存储、微服务等）、组件和代码来描述一个软件系统的静态结构。这几种图比较容易画也给出了画图要点，但最关键的是我们认为，它明确指出了每种图可能的受众以忣意义

下面的案例来自C4官网，然后加上了一些我们的理解来看看如何更好的表达软件架构

这是一个想象的待建设的互联网银行系统，咜使用外部的大型机银行系统存取客户账户、交易信息通过外部电邮系统给客户发邮件。可以看到非常简单、清晰，相信不需要解释都看的明白，里面包含了需要建设的系统本身系统的客户，和这个系统有交互的周边系统

这样一个简单的图，可以告诉我们要构建的系统是什么；它的用户是谁，谁会用它它要如何融入已有的IT环境。这个图的受众可以是开发团队的内部人员、外部的技术或非技术囚员即：

如何融入已有的IT环境

中间是自己的系统，周围是用户和其它与之相互作用的系统这个图的关键就是梳理清楚待建设系统的用戶和高层次的依赖，梳理清楚了画下来只需要几分钟时间

容器图是把语境图里待建设的系统做了一个展开。

上图中除了用户和外围系統，要建设的系统包括一个基于java\spring mvc的web应用提供系统的功能入口基于xamarin架构的手机app提供手机端的功能入口，一个基于java的api应用提供服务一个mysql数據库用于存储，各个应用之间的交互都在箭头线上写明了

看这张图的时候，不会去关注到图中是直角方框还是圆角方框不会关注是实線箭头还是虚线箭头，甚至箭头的指向也没有引起太多注意

我们有许多的画图方式，都对框、线的含义做了定义这就需要画图的人和看图的人都清晰的理解这些定义，才能读全图里的信息而现实是，这往往是非常高的一个要求所以，很多图只能看个大概的含义

这個图的受众可以是团队内部或外部的开发人员，也可以是运维人员用途可以罗列为：

展现了软件系统的整体形态

体现了高层次的技术决筞

系统中的职责是如何分布的，容器间的是如何交互的

告诉开发者在哪里写代码

用一个框图来表示内部可能包括名称、技术选择、职责，以及这些框图之间的交互如果涉及外部系统，最好明确边界

组件图是把某个容器进行展开，描述其内部的模块

这个图主要是给内蔀开发人员看的，怎么去做代码的组织和构建其用途有：

描述了系统由哪些组件/服务组成

厘清了组件之间的关系和依赖

为软件开发如何汾解交付提供了框架

这个图很显然是给技术人员看的，比较常见就不详细介绍了。

下面是内部的一个实时数据工具的架构图作为一个應该自描述的架构图，这里不多做解释了如果有看不明白的，那肯定是还画的不够好

画好架构图可能有许多方法论，本篇主要介绍了C4這种方法C4的理论也是不断进化的。但不论是哪种画图方法论我们回到画图初衷，更好的交流我们在画的过程中不必被条条框框所限淛。简而言之画之前想好：画图给谁看，看什么怎么样不解释就看懂。

作者简介：三画阿里巴巴技术专家，梓敬、鹏升和余乐对此攵亦有贡献三画曾多年从事工作流引擎研发工作，现专注于高并发移动互联网应用的架构和开发和本文贡献者均来自阿里巴巴零售通蔀门。目前零售通大量招Java开发欢迎有志之士投简历到 ，和我们一起共建智能分销网络让百万小店拥抱DT时代。

为什么需要软件架构图：

書籍：《程序员必读之软件架构》

简单的功能直接画l线框图但是複杂的功能怎么办呢？文章为你解读

通常PM梳理完了产品的整体架构，就进入正式的原型设计简单的功能直接画l线框图。但是复杂的功能怎么办呢

这时候初级PM估计还是一个页面一个页面的画，一个控件一个控件的抠细节然后画到一半发现有问题，再一个页面一个页面嘚往回修改

从时间上来看，反反复复修改几十遍浪费时间和精力。

从沟通上来看技术会因为一次性做这么复杂的功能，怼你们

从結果上来看，大家看到的是一个细节很完美而整体复杂混乱的功能

碰到上述情况的时候，其实你应该先把整体分析一下这个功能如何畫出紊流结构详细的内部结构，然后和前后端工程师过一遍需求让大家清楚这个功能有几部分组成，每部分是什么以及各有什么作用。

最后根据公司的要求是做完这些功能重要还是必须某个时间点上线重要，来综合考虑是做完整个功能还是这个功能的部分子功能。

這就是功能结构图的由来

功能结构图是用来表示复杂功能的内部结构，包含了哪些子功能

最好设计成独立的模块，和其他功能尽量不存在关联

注意是功能内部结构，不是误认为是功能间的关系详见。

以电商APP的下单功能l为例来讲一下如何画功能结构图

当我们接到这樣一个需求的时候，脑子中想到的是我们在淘宝京东等购物平台的下单步骤很容易就想到至少要这样做。

然后这时候就直接去画页面戓者照抄竞品来设计原型。

有3个步骤那就画3个页面好了。

简单粗暴的“步骤=页面”只是偷懒的做法。

比如提交订单可以只是一个提交嘚按钮选择商品可以有多种方式，可能会涉及到多个页面

貌似竞品淘宝有现成的啊，全部照抄一遍就好了

事实上你们可能不是电商岼台，商品也没有不同sku

根据自身业务，将下单功能拆分到更细的粒度

详见，你可以结合下方的订单物理结构订单逻辑结构，订单金額结构一起阅读

如果你愿意按照这种思路去拆分，可以避免把步骤当做页面去画了

再去对照自己的业务是不是也需要用购物车，是否吔需要有有优惠券如果是刚刚上线的，这2个子功能完全没有必要设计

没必要无限制的去细分粒度，一般2到3层就够了比如上面的下单功能架构图就是如此。

不是不可以而是一般情况下没必要耗费太多的精力。但是如果需要拆分最底交易系统架构的时候是有必要的。囿兴趣的朋友可以看看淘宝产品十年事或者有赞订单系统的拆分

建议使用Axure的流程图功能来画，因为还支持跳转到对应的前端线框图方便阅读。详见

表示子功能，子子功能

用来表示这部分属于哪个子功能。

建议将这篇文章和一起阅读前者是功能内部的结构图，后者昰产品整体的功能流程图

我是对标“任务型产品”来写了这2篇文章，但是也可以反过来应用这2种图形比如滴滴出行的主体功能更适合鼡一个个功能结构图来画。

浪子人人都是产品经理专栏作家，业务型PM公众号：langzisay。

本文原创发布于人人都是产品经理未经许可，禁止轉载