认识达内从这里开始

随着互联网的不断发展，越来越多的程序员都在向架构师岗位转型发展，而今天我们就通过案例分析来了解一下，软件架构图设计常见问题分享。

方框或其他形状表示什么意思?

随意使用方框或其他形状可能会引起误解。这些形状有可能表示数据、代码或者流程。一个简单的方框可能会引起多种猜想，所以很有必要显式地给这些形状添加有意义的说明。

形状的边线表示什么意思?

在一个糟糕的架构图里，形状的边线(虚线、点线，等等)可能会引起误解。边线是否表示某种组件类型(比如虚线表示容器、微服务、层，等等)，或者只是因为设计者想让架构图的观感看起来更加丰富一些?所以，在使用多种边线或非标准边线时，要在图例里提供准确的说明。

线条或箭头表示什么意思?

线条或箭头可以被理解为数据流(比如从系统A到系统B的数据流)或元素间的关系(比如组件A依赖组件B)。在大多数情况下，箭头所表示的关系或数据流并不会总是汇聚到同一个方向上，所以很有必要在图例里说明清楚。

线条或箭头表示哪一种类型的交互或关联?

尽管线条可以表示数据流或组件间的关系，但用于表示交互类型(对于数据流而言)或关联类型(对于关系而言)的线条或箭头仍然需要详细说明。例如，如果使用线条表示数据流，那么交互类型可以是同步或异步的，但如果线条表示的是关系，那么关联类型有可能是指依赖、继承、实现，等等。这些细节必须在图例里说明。

颜色代表什么意思?

一个使用了多种颜色的架构图却没有适当的文档说明很容易引起误解(比如为什么有些方框是绿色的，而其他是红色的?为什么有些线条是黑色的，而有些是蓝色的?)。颜色在架构图里的作用不是非常大，添加太多的颜色并不会给架构图带来更多有价值的信息。一个仅仅使用了黑白两色的架构图也应该是不言自明的，除非非常有必要使用特定的颜色来强调图中的某些部分。在任何情况下都要保持颜色的简单性，如果一定要用多种颜色，不要忘了添加说明。

单独的元素或实体

如果架构图中出现了单独的元素或实体，说明架构图有可能是不完整的。不管是从结构还是从行为角度来看，每一个元素或实体都应该依赖系统的其他部分，或者与它们之间存在某些联系。

费解的缩略语或含糊不清的名词

在为架构图中的元素添加标签时，切忌使用费解的缩略语，这样容易引起困惑。如果没有恰当的说明，字母的堆叠(比如TFH、RBPM，等等)就毫无意义，好在图例里进行说明。

在给元素命名时，另一个常见的问题是使用了含糊不清的名词(比如业务逻辑、集成逻辑)，这些名词并不能做到自解释。代码里可能也会存在这样的问题，我们建议遵循清晰的代码原则，使用自解释的名字。

在架构图中详述技术、框架、编程语言、IDE或开发方法论

架构图并非以技术、框架、编程语言、IDE或开发方法论为基础，它们只是用来实现架构的工具，而不是中心关注点。它们不应该被包含在架构图里，不过可以在架构描述里简述使用它们的理由。

在同一个架构图里混杂运行时元素和静态元素

运行时元素(比如线程、进程、虚拟机、容器、服务、防火墙、数据仓库，等等)不会出现在编译阶段，而且不应该与静态元素(比如组件、包、类)同时出现在同一个架构图里。针对运行时元素有专门的类型图(比如并发图、部署图)，一定要注意区别这两种元素，尽可能避免把它们混杂在一起。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。