既是业务模型的抽象更是技术的抽象



架构是对业务的抽象后的技术抽象实现，这样即可以和从业务人员来沟通对业务的模型，也能和技术人员探讨业务具体实现方案。这样来看架构师是为业务（其实产品经理负责业务梳理和裁剪）和技术人之间的搭建一座沟通桥梁或者通道。



架构产物-架构图

架构图是对软件系统的立体呈现

架构又是对一种技术实现的一个建模，所以在架构文档中会涉及到4+1的图形，包括逻辑视图，开发视图，过程视图，物理视图，用例图，而所有的这些图，其实都是为了对业务的一种技术实现建模，然后方便业务了解系统，指导技术人员实现。



架构图是对系统的一个立体抽象的描述，就像建筑图里面有各种横截面设计，他会从三维的角度去看这个建筑是怎么设计的，而软件设计的架构图也是同理，也是为了对软件系统有一个立体的认识，所以产生了4+1的图对系统进行一个立体的描述让所有的系统相关角色都能够了解到系统是什么？系统在做什么？系统是怎么做的？系统是怎么实现的？为的系统是怎么部署的？





架构图的统一语言



那既然这些架构图是为了在业务和技术之间产生一种沟通交流，那么就需要一种语言来表达、描绘这个这个架构模型图，而这种语言就叫UML(Unified Modeling Language)，所以这里我们就能看到这个 UML 的作用其实是一种业务架构的表达语言。





UML 这词也再次说明了，而是一种语言，具体的业务实现模型怎么去画？还是应该对业务有很深刻的认识。架构图形的元素，其实很简单，但是业务的抽象是相当复杂的一个过程，在这个过程中，架构师需要对业务的细节与有人员进行深入的探讨，并对业务进行反复确认，才能确保自己对业务的认知是正确的，这样才有可能设计出正确的架构。



架构图

正是因为这些图是可以不同的角色去看的，所以我们在画这些图的时候一定要注意你这个图是给谁看的？在这个前提条件下，你去画这些图，才能画出针对性的图来，而不能为了画图而画图，然后画出一堆图来，结果你的用户看不懂。这就是糟糕的一种状态，所以我们还是要有一种针对性的工作，要明确我们的服务对象是谁，怎样做用户才更满意，才能更高效的沟通协作。



工作不是只为工作，而是要明确工作的价值所在。

架构产物-架构文档



架构图比较是一个浓缩版的抽象图，很多图的细节还需要文字描述，这样架构文档就应用而生。架构对相关业务细节的要求描述之外，还有一些非功能性的需求架构实力，也需要去考虑，比如说每个响应的时延，然后系统的整个容量规划，安全性，风险，已经技术选型等都应该去考虑到。



架构不只是一种技术，更是一种艺术



架构不是一蹴而就，是根据业务需求不断演进的。架构不只是技术方案，是一种权衡的艺术。所以学架构不是学架构的方法，而是一种架构处理问题的思路，是高于技术的一种艺术，所以需要大家去悟，悟道。



成年人的世界只有利弊没有对错





架构需要一定的技术积累，更需要自己的思考和各路大牛沟通的思想碰撞，沉淀下来技术精华。软件行业还是一个年轻的行业，还需从别的行业吸取更多的行业最佳实践，从而通过软件、通过软件架构反哺各个行业。