阅读笔记--《一线架构师实践指南》--Refined Architecture阶段
Refined Architecture，直接翻译为【精致的建筑】，这是本书的第三个部分，前两个阶段按分别为pre-Architecture阶段、conceptual Architecture阶段，两个阶段分别为【前架构】、【概念架构】，我自己对这写阶段的理解就是，一栋建筑物的形成过程，在正式架构之前，要了解这栋建筑的用途，居民楼？学生公寓？购物广场？政府大楼……，将情况了解清楚之后，进行概念架构，也就是要求不是特别多的一种大体概括，画出建筑物的草图，这些工作都完成之后，来到第三阶段，就是对这栋已经有些身影的建筑来精细设计，将其变为移动精致的建筑。将建筑替换成我们的软件，就是首先了解这个软件，这个系统各方各面的需求，然后进行系统的概念设计，具有哪些功能等等，之后来到这一Refined Architecture阶段，及对软件系统进行精确的设计。
书中的这部分包括第11-15章，分别讲了细化架构的故事、Refined Architecture总论、逻辑架构、物理架构、运行架构、开发架构、以及数据架构的难点——数据分布。
对于两个关于细化结构的故事——骄傲的架构师，郁闷的程序员以及办公室里的争论，我的感想如下，两个故事指出细化架构以及五视图方法实践的重要性，正如书中提到的两句名言
“如果一个项目的系统架构（包括理论基础）尚未确定，就不应该进行此系统的全面开发。”
“如果选择视图的工作没有做好，或者以牺牲其他视图为代价，只注重一个视图，就会冒掩盖问题以及厌恶解决问题（这里的问题是指那些最终会倒是失败的问题）的风险。”
第一个故事是在《方案书》确定之后，架构师觉得方案书被认可说明架构已经很明确，无需“再”架构，但是程序员并没有在实际开发中得到足够的指导和限制，这就是在第一个名言中所描述的“项目的系统架构尚未确定”，及概念架构之后没有进行深一层次的“规约”设计，及细化架构，细化架构及概念架构的区别如下表1：
| 细化架构 | 概念架构 | |
| 接口 | 核心地位 |
不关心明确的结构定义 （只有抽象的组件和抽象的加交互机制） |
| 子系统 | 通过子系统和模块来分割整个系统，并且子系统往往有明确的接口 | 抽象的组件没有接口，只有职责（一般为处理组件、数据组件、连接组件），有大组件分为小组件 |
| 交互机制 |
“实在”的 结构标称、消息机制、远程方法调用 |
“概念化”的 A层使用B层的接口 |
还了解到了，“方案”和“架构”的关系，我的理解笔记如下图：
第二个故事，办公室关于“什么是架构”的争论，程序员、程序经理、系统分析员、配置管理员、数据库工程师、部署工程师、用户这些角色都站在自己的立场发表了观点，提出了自己角色对应的“视图”，这里指出了第二个名言中所提到的“选择视图的工作”，最后给出了贴近实践的多视图方法，应将一线架构师的各项具体工作涵盖其中，如下图：
|
表2 实际工作中架构师的工作范围 |
|
|
运行架构 |
接口、线程 |
|
逻辑架构 |
接口的定义 子系统的划分 结构化方法的模块 逻辑层 |
|
物理架构 |
服务器的类型 物理层 |
|
开发架构 |
源程序目录 |
|
数据架构 |
数据分布与数据库 文件格式 Flash存储结构 |
关于视图：
- 视图的意义是利于思考（因为分而治之的思维方式）、便于交流（因为在一定程度上分离了涉众关注点）；
- 视图并不是阶段，如逻辑架构与物理架构只是同意阶段需要考虑的两个方面；
- 在总图中，每一个视图是一个思维角度，要从不同角度出发，规划“分割”与“交互”；
- 在详图中，每个视图是一组技术关注点；
逻辑架构——划分子系统、定义接口
划分子系统的三种方法：分层的细化、分区的引入（架构中引入分区，支持深度优先的迭代开发）、机制的提取（基于接口（或抽象类）的协作是机制，基于具体类的协作则算不上机制；实现不同的最终功能可以重用同一个机制），及“总-分-总”
划分子系统的四个重要原则：职责不同的单元划归不同子系统； 通用性不同的单元划归不同子系统； 需要不同开发技能的单元划归不同子系统； 兼顾工作量的相对均衡，把太大的子系统进一步做切分。
定义接口，避免“我的接口我做主”的错误思想，要协作定义
