要点设计软件模式映射不是一件容易的事情，简单的模式映射也可能会导致错误。 有意义、一致的体系结构图有助于澄清各种利益攸关方的事实并达成共识。 大多数情况下，问题的根本原因不是是否使用了有效的模式描述语言(如UML )，而是低估了模式映射的重要性，依赖于不正确或不一致的指导方针，或者缺乏模式思维。 在生成模式图的过程中，尝试将自动生成的要素和手动生成的要素混合使用，可以减少工作量，还可以表达各方面的关注点，覆盖到系统的各个层面。 系统不断发展，维持模式映射的更新需要额外的劳动力。 您需要知道如何有效地应对这种情况，同时保持体系结构图的一致性和健壮性。
现代软件架构导致了更高的复杂性，这些都反映在架构图上。 曾经，我们的软件项目需要体系结构图。 无论是否遵循正式的体系结构模式(如Kruchten 4 1、Rozanski Woods等)，都必须将部分APP应用程序记录在图表中。 在软件体系结构中，这些图表通常是根据作为模型一部分的特定视图设计的。 但是，本文倾向于使用模式映射这个术语。 因为那个看起来不那么正式，所以关于其他领域的内容在这篇文章中就不会涉及了。
作为软件架构师和技术培训师，根据我的经验，在项目之间以及同一团队的开发人员之间创建模式映射的方式也不同。 我看到过很多问题，比如一致性问题、碎片问题、信息粒度大小问题、图表外观问题等等。 与模式模型的正式化和标准化相比，模式映射不需要那么正式，也不需要遵循任何标准。
相关厂商内容百度PB级数据仓库Palo开源架构Snapchat大规模个性化推荐引擎解读微信社交广告核心架构与图形计算存储摩拜单车：通过机器学习等技术实现自行车
相关赞助商
但是，模式映射必须是自描述的，并且必须一致和足够准确以适应代码。 因此，架构师和软件工程师是理解结构、元素、关系、属性、原则等APP体系结构的基础，也是不同技术背景和兴趣相关方的交流基础，因此在创建模式图时存在各种各样的问题
在详细说明当前体系结构图的不足之处之前，我想引用一句英语谚语：“一张照片胜过千言万语”。 Wiki解释说：“这句谚语的意思是，复杂的想法是否可以用静态图像表达，照片是否可以表达主题的意思，图像比用文字说明更直接有效。” 模式映射也是如此。 如果引起的疑问比可以解释的问题多，那就不是好的模式映射了。 好的体系结构图不需要额外的文字说明！
图：不好的体系结构图通常存在以下问题。
这里，坏的模式映射有什么问题？ 这些问题妨碍我们创建良好的模式图。
盒子和其他形状是什么意思？ 自由使用盒子和其他形状可能会引起误解。 这些形式可能表示数据、代码或过程。 一个简单的方框可能会引起很多猜想，所以需要在这些形式中明确添加有意义的说明。
形缘是什么意思？ 在不良的体系结构图中，形状的边界线(虚线、点线等)可能会引起误解。 边界是否表示组件类型，如容器、微服务器或层？ 或者，是因为设计者想让模式图的外观看起来更丰富吗？ 因此，如果使用多条线或非标准线，则必须为图例提供准确的说明。
线和箭头是什么意思？ 线条或箭头可以理解为数据流(例如从系统a到系统b的数据流)或元素之间的关系(例如组件a依赖于组件b )。 在许多情况下，箭头表示的关系和数据流并不总是在同一个方向上聚集，因此需要在图例中进行说明。
线或箭头表示什么类型的相互作用或关联？ 线条可以表示数据流或组件之间的关系，但对于数据流，表示交互式；对于关系，表示关系类型的线条或箭头需要详细说明。 例如，如果在数据流中使用线条，则交互类型可以是同步的或异步的。但是，如果线条表示关系，则关系类型可以是依存关系、继承关系、实现等。 这些细节必须在图例中说明。
颜色是什么意思？ 使用多种颜色的模式映射，如果没有相应的文档说明，很容易引起误解(例如，为什么一些块是绿色的，而其他块是红色的？ 为什么有些线是黑色的，有些是蓝色的？ 请参阅。 颜色在模式映射中的作用不是很大。 添加太多颜色不会在模式映射中增加有价值的信息。 除非需要使用特定颜色来强调图的一部分，否则只使用黑白两种颜色的模式映射也应该是显而易见的。 如果在任何情况下都必须保持颜色的简单性，并使用多种颜色，请不要忘记添加说明。
如果单个元素或实体模式映射包含单个元素或实体，则模式映射可能不完整。 无论在结构上还是在行为上，每个元素或实体都必须依赖于系统的其他部分，或者与它们之间存在某种联系。
费解的缩写或模糊的名词
标记模式映射中的元素时，请不要使用令人费解的缩写。 那样的话，容易引起混乱。 如果没有适当的说明，字符的堆叠(例如TFH、RBPM等)没有意义，最好用图例来说明)例如TFH是ticket feed handler，RBPM是rates business process manager。
在命名元素时，另一个是
个常见的问题是使用了含糊不清的名词（比如业务逻辑、集成逻辑），这些名词并不能做到自解释。代码里可能也会存在这样的问题，我们建议遵循清晰的代码原则，使用自解释的名字。 在架构图中详述技术、框架、编程语言、IDE或开发方法论架构图并非以技术、框架、编程语言、IDE或开发方法论为基础，它们只是用来实现架构的工具，而不是中心关注点。它们不应该被包含在架构图里，不过可以在架构描述里简述使用它们的理由。
在同一个架构图里混杂运行时元素和静态元素
运行时元素（比如线程、进程、虚拟机、容器、服务、防火墙、数据仓库，等等）不会出现在编译阶段，而且不应该与静态元素（比如组件、包、类）同时出现在同一个架构图里。针对运行时元素有专门的类型图（比如并发图、部署图），一定要注意区别这两种元素，尽可能避免把它们混杂在一起。
“稍后详述”或“稍后解释”
不包含在架构图里的任何信息都有可能丢失，而架构图里并没有额外的地方可以容纳口头说明。所有的口头说明都会丢失，当其他利益相关者（比如开发人员、架构师）查看架构图时，他们并不知道原来还有所谓的口头说明。试着把所有必要的信息都包含在架构图里，而不是事后加以说明。
层级冲突或混合抽象
在同一个架构图里添加不同层级的抽象可能会导致冲突的出现，因为它们是从不同的角度描述问题的。例如，把组件添加到上下文架构图里，或者把类加到部署图里，这些都会偏离架构图原先的目的。在创建架构图时，试着保持相同的抽象层级。
使用混乱或含糊不清的架构图表达过量的信息或无效的细节
爱因斯坦曾经说过，“凡事应该尽可能简单，简单到极致”。对于架构图来说也是一样的，我们需要谨慎地选择信息的层级和粒度，这并不是一件容易的事情，它取决于所使用的架构模型、架构师的经验和系统的复杂度。
在创建架构图时可参考的指南
除了上面列出的问题清单，还可以参考如下的一些指南来创建更好的架构图。
选择最优的架构图数量Philippe Kruchten说过，“架构是一项复杂的工作，只使用单个图表来表示架构很容易造成莫名其妙的语义混乱”。要对系统进行良好的文档化，我们不能只使用一种图表。不过在创建架构图的时候，我们也难以确定该使用哪些类型的架构图以及应该创建多少个。在做出决定之前，我们需要考虑多方面的因素。例如，架构的属性和复杂度、架构师的技能和经验、可用的时间、维护成本，以及利益相关者的关注点。网络工程师可能想看到包含了主机、通信端口和协议的网络模型，数据库管理员更关心如何系统是如何操作、管理和分布数据的。所以，我们要选择最优的架构图数量，不管这个数字是多少。
糟糕的架构图（比如缺乏文档）可能会缺失一些信息，反过来说，如果架构图太多（比如过度文档化），那么用于保持架构图一致性和更新架构图的工作量也会相应增加。
架构图之间应该在方框、形状、边框、线条、颜色等方面保持一致。架构图的结构外观应该是一样的，团队不同成员创建的架构图不应该给任何一个利益相关者造成理解上的障碍。理想情况下，可以在所有项目里使用相同的建模工具。
从语义角度来看，所有的架构图与最新的代码变更之间以及架构图与架构图之间都应该定期保持同步，因为一个架构图的变更可能会影响到其他架构图。同步可以通过手动进行，也可以通过建模工具自动触发。通过建模工具自动触发会更好一些，不过这也取决于具体的项目。最终的目的是要保持架构图和代码之间的一致性，至于使用什么样的方法或工具可以自行决定。Simon Brown说，“如果架构图与代码失去了联系，那么就无法用来改进架构”。他的话其实是在强调保持语义一致性的重要性。
避免架构图碎片化
架构图越多就越难以理解，而且维护起来也很费劲。最直接的后果就是有可能出现碎片化（比如，通过两到三个架构图来描述同样的质量属性——性能、伸缩性，等等——但每一个架构图都无法完整地描述它们）。在这种情况下，建议移除不能反映相关质量属性的架构图，或者把它们合并起来。
保持架构图的可追踪性保留架构图的变更记录、比较不同版本架构图之间的不同点，以及可以很容易地进行回退，这些都是很重要的。如果建模工具不支持这几点，那么对我们来说可能会是个问题。最近业界倾向于使用简单而直接的文本语言来生成架构图，这样似乎可以解决可追踪性问题。这样做的另一个好处是可以保持架构图之间的结构一致性。
在架构图旁边加上图例
如果你没有使用标准的架构描述语言（比如UML、ArchiMate），那么就要在图例里注明每个架构图元素的用意（比如方框、形状、边框、线条、颜色、缩略语，等等）。
如果使用了标准的架构描述语言，只要在图例里添加关键性的架构描述，不需要太多额外的信息，因为看图的人都知道如何按照标准的描述语言规范来理解你的架构图。
使用架构描述语言（比如UML、ArchiMate等）会有不一样的效果吗？
关于如何在项目里使用正确的架构描述语言有很多不同的看法。有些人认为UML太过死板，用来做架构设计缺乏灵活性，在某种程度上我认同这个看法。有时候，在不依赖UML的profile和stereotype特性的情况下也能很好地完成架构图设计。至于说到其他的架构描述语言，我认为ArchiMate更加强大，相比UML，它更适合用来为企业系统建模。还有BPMN，它更专注业务流程的建模。对这些工具进行深入比较已经超出这篇文章的范围，所以不再累述。
在选择架构描述语言时，综合性和灵活性是首要考虑的因素。但据我所知，完全不使用架构文档的情况也很常见。有些人觉得创建架构文档是一件很无聊的事情，而且觉得它们没有什么意义。这样的项目应该不在少数。人们因为没有使用合适的架构描述语言，所以创建不出很好的架构图，相反，如果他们使用了更好的工具，结果可能会大不一样。但事实并非如此，实际上他们跟本不想去创建什么架构文档（包括架构图），更糟糕的是，他们可能不知道该如何创建架构图。这是我们首要解决的问题——了解文档的重要性以及如何创建它们（给软件工程师做培训），然后选择合适的工具。
在系统和架构发生变化时如何更新架构图？更新架构图有几种方式，我将会介绍其中的三种。第一种，也是最简单的一种，就是直接从代码生成架构图。这样可以保证架构图与代码是一致的。不过目前的工具还不能完全支持这种方式，在没有人工介入的情况下，工具还无法基于代码生成精确且有意义的架构图。Len Bass说，“在最理想的开发环境里，只需要一个按钮就能得到我们想要的文档”。他指的就是自动生成架构图，但我们还远远没有达到那种程度。
第二种，先用建模工具创建架构图，然后生成代码骨架（比如组件或包、API），随后开发人员可以在骨架上添加代码。每次架构图发生变更，需要从架构图端重新生成代码骨架。
第三种，在每次加入新特性时手动更新架构图。为了保证代码与架构图的一致性，建议把更新架构图作为开发流程的一部分。不过我们不推荐这种方式，因为这样很容易造成架构图过时或出现不一致（比如开发人员总是忘记或者不想更新架构图）。
我的建议是混合使用现有的工具，结合手动和自动的方式来创建架构图。例如，尝试自动生成架构图，使用工具基于代码渲染出符合基本要求的架构图，不包含混乱无用的信息。架构图可以高度可变（比如可以适应频繁的开发变更，这类架构图一般具有较低层次的抽象），也可以是静态的。这类图表可以是上下文架构图、参考架构图、包图、类图、实体图，等等。不过有时候仅仅基于代码无法生成满足需求的架构图，所以在这种情况下，自动创建架构图不是理想的方式。这个时候需要手动建模作为补充，这类架构图包括时序图、状态图、并发图、部署图、运营图，等等。
现代架构（如微服务）对架构图有什么影响？微服务或其他任何一个现代架构风格（如无服务器、事件驱动）只会影响到系统的结构、组件间的交互方式（比如组件间的关系）和原则。在我看来，我不认为架构风格会改变架构图原先的含义。不过，相比传统的系统（比如单体），我们所说的现代系统架构具有更高层次的复杂性，它们对架构描述和架构图确实会有一些影响，这些是我们需要注意的。我们需要考虑分布式组件（比如分布式微服务）、每种组件的类型、组件间的交互方式（比如边界、API、消息）、他们的生命周期以及从属关系。
综上所述，我们需要在架构图中体现系统的分解、开发、部署和运维。假设有一个包含了大量微服务的系统，它就会有很多的架构图，因为每个微服务都可能有自己的架构图。一致性（例如，改变一个服务的API会影响到其他服务，所有相关的架构图都需要做出修改）、碎片化（例如，一个架构图无法反映分布式服务的高可用性和性能）和横断面（例如，是谁在负责处理系统的监控或安全问题）问题会让人手忙脚乱。我们首要面对的挑战是如何进行良好的团队协作，不仅仅是开发，也包括后续的维护。
总而言之，现代系统的复杂性会带来额外的问题，它们会在架构图层面造成一定程度的影响。
作者 ： Ionut Balosin是Luxoft的软件架构师，拥有十年以上的应用程序开发经验，专注性能调优和软件架构。他是开发大会的演讲常客，也是一名技术培训师。
出处： http://www.infoq.com/cn/articles/crafting-architectural-diagrams版权申明：内容来源网络，版权归原创者所有。除非无法确认，我们都会标明作者及出处，如有侵权烦请告知，我们会立即删除并表示歉意。谢谢。
更多原创文章详见: http://chillyc.info