架构的方法：运用合适的工具表达设计

1、架构设计的关键在于思维。
不是因为PPT里的大部分内容讲的是UML，就花大把时间去学习如何画UML图，去尝试各种UML工具，去理清各种UML图的细节，而是要理解UML图背后所代表的看待架构的思维。
比如，用例图，它从用户的角度来描述系统的功能以及各个功能的执行者，强调的是使用者和功能。它从使用者的角度来看待一个系统，可以帮助我们从宏观上理清系统的所有功能点以及各个功能点之间可能存在的联系。
再如，时序图，把用例图表达的功能点，转化为更进一步，更加精细的表达，它几乎是自描述的，并且显示了流程中不同对象之间的调用关系，同时还可以很详细地显示对不同对象的不同调用。它从开发者的角度来看待系统，让系统的关键流程变得容易理解，特别有利于初级开发者或对业务不熟悉的同学。
最后，比如部署图，更强调系统运行时需要的物理节点以及各个节点的配置，其强调物理设备之间的关联关系。它更多的是从运维的角度来看待系统的，可以帮助运维理清该如何部署以及平衡物理资源的分布。
综上，UML背后体现的思维是：在软件的不同阶段，站在不同的角度，通过不同类型的图表来指导架构的设计。我觉得，UML更多的意义在于表达，即通过一些标准化的约束和图表来描述我们的设计。所以，很遗憾，UML并不能教你如何设计，它只是一个工具而已。
很赞同的一个关于架构设计思维的观点是：架构设计的关键思维是判断和取舍，程序设计的关键思维是逻辑和实现。
所谓判断，即通过对需求的理解，识别系统复杂性所在的地方，并针对这些复杂点进行架构设计。所谓取舍，即有的放矢，而不是面面俱到。
比如，对于一个确定的功能点，不同的性能要求，设计思路是不一样的。如果性能要求不高的话，不需要使用缓存，也无需引入各种中间件；而如果性能要求很高的话，可能就需要使用消息队列和缓存等组件来提升性能。
但也要避免陷入贪大求全的境地，不根据实际情况，什么都想满足，既要高可用又要高性能，这就是没有很好的进行取舍和平衡。
判断和取舍才是架构师在架构设计时，应该着重关注的点，如果仅仅是通过UML把各种图表画出来，更多的还是停留在工程师思维，仅关注了程序的逻辑和实现，这并不有利于我们做出好的架构设计。
而如何进行判断和取舍，则要看我们在技术深度和广度上的积累，这不是参加一个训练营就能解决的问题，只能说道阻且长，我们还需努力。

2、关于人
架构设计的第二个要点是人，即相关方。
在架构设计中，相关方指的可能是系统的各个角色用户，即什么样的人会如何使用系统；也可能是实施整个架构的开发工程师、测试工程师以及运维工程师；甚至可能是要时刻关注系统研发的老板等等。
不同的相关方，对架构设计的成果的期待是不一样的，这个需要根据团队的实际情况来考虑和取舍，这也是指导架构师设计的重要标准。
比如，对于老板，其可能更关注实现整个架构需要的人力、物力、时间成本；而对于项目经理可能会更关注架构的边界以及和其他团队的协作配合上；对于开发工程师，可能更关注架构涉及到的各种技术以及实现方式。作为架构师，需要考虑不同相关方的期待，以此来指导设计。
特别想说的是，整个架构设计要特别关注的角色，其实是开发工程师。在架构设计中要根据开发工程师的技术水平给予适当的发挥空间。如果团队都是新手工程师，可能需要像课程中一样，细致到关键流程的时序图、类图，工程师只需要实现即可，这样可以最大程度的保证软件质量。而如果团队中有很资深的工程师，在关键业务流程以及组件使用上，最好与其充分讨论，得出一致结论。这时候，架构文档只要起到记录的作用即可，也就无需太细致，具体的实现留给工程师自己发挥吧。

3、关于工具
架构设计的最后一个要点是工具。在架构设计中，工具是一种语言。
既然是语言，其最重要的作用就是交流。只要相关方可以理解，选择什么样的工具就变得不那么重要。
UML作为标准建模语言，全世界通用，但如果你的团队没人学习过，那大可不必一定要使用。比如，用例图你完全可以画框图来代替；流程图也可以代替时序图的部分功能。
因此，工具的选择是与人紧紧相关，无关乎好坏优劣，选择合适团队的就好。
这也是为什么把工具的重要性放到最后一个的原因。就我个人而言，如果不是因为作业需要，短时间内不会去看或者学习任何UML相关内容，毕竟周围没人通过UML沟通和交流。也正如老师所讲，如有需要，花半个小时学习即可。