《一线架构师实践指南》第三编Refined Architecture阶段读后有感
第三编上来讲述了两个软件公司的小故事：《方案书》确认和办公室争论，这都是说明了架构不详细给我们工作中带来的不便。其中提到的探究“ 方案 ”与“ 架构 ”的关系，里边提到的方案对于细化架构来说就是将架构的细化，将系统里边的接口、子系统、交互机制交代清楚，让像我们这些刚入门的小白都比较清楚编程的方向；相比较而言，架构更像是江湖道行高深的老手们对整体结构的布局，但是不适合新手的程序开发者上手。虽然我们这一学年一直在学习关于架构的知识，但是对于“ 细化架构 ”这个概念也是第一次学到，感觉对于像文中提到的程序员来说，细化架构跟容易上手，但是相对来说有一些无脑了吧。
这里放一张书中的图，可以帮助理解概念架构和细化架构的层次：
接下来提到是第三编的主题关于对Refined Architecture的介绍。
第十二章在介绍完Refined Architecture的实际意义后提到了此行业的现状，我认为可以用书中的第二小节的标题为总结——误把“ 视图 ” 当 “ 阶段 ”。简单来说是将概念架构、逻辑架构、物理结构当作阶段一步一步完成，其实应该是合适的时间里同时进行一项或者多项，这才能起到视图的效果。书中也给出了正确的改正方式如图：
十三十四章分别详细讲述了Refined Architecture的架构方法，我也分别写一下。
首先提到的是逻辑架构，文中提到一线架构师不缺理论不缺技术，缺少的是将二者结合起来应用到项目中的实践策略和套路，所以演化出来了分层的概念，将之前泛泛的层次按照接子系统和接口细分，达到详细架构的目的。同时还有分区引入以及机制提取，简单来说引入分区是将分层细化；而机制引入就相当于规定先做什么后做什么，在编程的角度就是定义的先后顺序以及他们之间的协作关系等等。
然后是物理架构、运行架构、开发架构
- 物理架构：有时候增加硬件未必能够解决问题，单纯的增强硬件只是增加计算机的计算能力，所以需要满足软件系统的可靠性、可伸缩性等等才能提高效率，这就出现了物理架构。从设计结果层面，决策围绕物理节点、网络、软件单元、数据单元等内容展开进行方案的优化。
- 运行架构：当从设计结果层面，决策无非围绕物理节点、网络、软件单元、数据单元等内容展开。需要考虑控制流的创建、销毁、通信机制等。进一步考虑：控制流之间的同步关系，若有资源争用还要引入加锁机制。
- 开发架构：并行开发所需的“程序单元”、“源码目录”等，是不同程序团队根据自己团队的实际情况开展具体工作的基础。所以这一方面因团队而已，重点是多总结经验从而减少错误降低成本。