最近梳理了之前学习的架构设计相关的一些课程学习总结，将其整理成了一个大纲脑图，以每篇5分钟系列展现出来，希望对你有所帮助。
本篇，我们聚焦架构设计的理解部分。我们会从本质论、思维论、下定义和打比方四个方面来学习。
本质论
架构设计的主要目的是为了解决复杂度带来的问题。
从功能复杂度来看，主要解决的是业务发展带来的系统耦合、开发效率缓慢问题。
从非功能性复杂度来看，主要解决的是高性能、高可用、高扩展性等需求。
思维论
架构设计的关键思维是判断和取舍，而程序设计的关键思维是逻辑和实现。
真正优秀的架构都是在企业当前人力、条件、业务等各种约束条件下设计出来的，能够合理地将资源整合在一起并发挥出最大功效，并且能够快速落地。
下定义
软件架构指软件系统的顶层（Rank）结构，它定义了系统由哪些角色（Role）组成，角色之间的关系（Relation）和运作规则（Rule）。
Rank 分层：
Role 角色：
最常见的微服务拆分其实就是将整体复杂的业务系统按照业务领域的方式，拆分为多个微服务，每个微服务就是系统的一个角色。
Relation 关系：
指软件系统的角色之间的关系，对应到架构图中其实就是连接线，角色之间的关系不能乱连，任何关系最后都需要代码来实现，包括连接方式（HTTP、TCP、UDP 和串口等）、数据协议（JSON、XML 和二进制等）以及具体的接口等。
实际工作中，Rank、Role 和 Relation 都是通过业务架构图 和 系统架构图来展示的，如下所示：
业务架构图
系统架构图
Rule 规则：
指软件系统角色之间如何协作来完成系统功能，一般通过系统序列图来展示：
打比方
软件架构设计类似于大自然“设计”一个生物，通过演化让生物适应环境，逐步变得更加强大。
大自然“设计”过程：
首先，生物要适应当时的环境；
其次，生物要不断地繁殖，将有利的基因传递下去，将不利的基因剔除或修复；
第三，当环境变化时，生物要能够快速改变以适应环境变化；如果生物无法调整就被自然淘汰；而新的生物会保留一部分原来被淘汰生物的基因。
架构设计过程：
首先，设计出来的架构要满足当时的业务需要；
其次，架构要不断地在实际应用过程中迭代，保留优秀的设计，修复有缺陷的设计，改正错误的设计，去掉无用的设计，使得架构逐渐完善；
第三，当业务发生变化时，架构要扩展、重构，甚至重写；代码也许会重写，但有价值的经验、教训、逻辑、设计等（类似于生物体内的基因）却可以在新的架构中延续。
参考资料
李运华，《从0开始学架构》
刘海丰，《架构设计面试精讲》
潘新宇，《23讲搞定后台架构实战》
作者：周旭龙
出处：https://edisonchou.cnblogs.com
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文链接。
标签：架构设计,架构,角色,系统,架构图,了解,设计,分钟 From： https://www.cnblogs.com/edisonchou/p/architecture_design_learning_in_5mins_part2.html