架构实战体会,结合《蔡学镛：架构的5个观察角度》
架构是结构化的表征，结构重在看 ，会看才能发现其中的别有洞天之美。研究物理结构常常说：“横看成岭侧成峰，远近高低各不同”，通过不同的视角，会有不同的表征，如俯视图、正视图、侧视图，我们会有抽象思维能力(刻意练习)，快速形成空间抽象图像。
软件架构也是同样的思考方式，需要能够通过多视角观察，才能体会其门道，才能体会架构之美。在我日常的实战中，更多的是关注业务架构(需求)——>产品架构(功能、结构、行为)——>技术架构——>组织架构。重点说一下组织架构，基于架构师的职责应该是技能完成好设计，又能灵活利用资源完成架构的落地，因此我在做产品、技术架构的同时，比较喜欢近一步考虑人员结构，如何让人员的能力与软件架构的工作形成较好的匹配，来顺利的完成架构的实现。以上是软件建设过程的组织架构。随着软件的建设，软件与业务相结合，从康威定律的理解，软件结构会影响组织架构，运行态的软件一定是与维护组织结构有良好的映射，如果不能建立很好的映射，就会面临架构的落地困难问题。
在阅读本文后，对于数据架构、网络架构我接触较少，可能是跟项目属性偏业务更多有所关系，或者我更愿意将数据架构和网络架构放在技术架构中考虑，当然这才建设期数据和网络是技术的重要组成部分，但是站在业务或者运行态的视角考虑，数据架构一定很重要，站在运维视角考虑，网络与部署架构则更加重要。由此可得出一个结论，架构有众多视角，但是更重要的关注什么视角，取决于你的角色，根据角色(业务、技术、运维……)而选择观察关注的侧重点。
文章对于架构观察视角的分类有：鸟瞰架构、剖面架构两个维度，剖面有可以有横剖、侧剖，鸟瞰相对更加宏观，更加能表达蓝图，剖面体现内部结构，体现细节，我对微服务架构的理解其实也是类似的思考，微服务=微服务节点+微服务关系，微服务是一个宏观架构-鸟瞰，节点+关系便是一种图结构的剖面关系，微服务节点有其功能特性也有其内部剖面结构。同样对于微服务，其实可以近一步谈数据架构、领域设计架构、安全架构、网络架构等，这些也是微服务在不同视角下的剖面架构。
文章关于应用系统的分层也有所启发，文章分为：UI、应用、框架、服务、核心、驱动、数据，感觉这个可能是过去架构的最佳实践，首先按应用层和核心层可以分为应用层包含UI、应用、框架、服务；核心层包含核心、驱动、数据，对于核心业务和数据之间架设的驱动层，可以将业务与数据解耦，而让驱动层变为可拔插的架构，数据库这么多年便是这样干的。核心层与应用层的区分可以参看操作系统，内核态和应用态，通过内部接口进行衔接。服务指围绕一些核心业务的功能封装，属于中台性质，一般服务之上是应用，应用是面向业务场景的特性化封装，但是我们可以在之间架设框架层，可以近一步抽象变化，提升服务适应业务场景的开发效率。相对简单指页面层。
以上是结合文章与日常架构工作的一些思考理解，架构谈来谈去，还是从不同的视角理解结构，以形成准确清晰的结构抽象。
参考文章：蔡学镛：架构的5个观察角度
https://mp.weixin.qq.com/s/Co-5ZafexBhd1aYSnfEWDw
