Refined Architecture阶段就是相对于Conceptual Architecture而言，分别对应于“概念级”解决方案和“规约级”解决方案。
Refined Architecture（细化架构）属于架构设计，不能与Detailed Design（详细设计）相混淆。架构领域最喜欢将建筑设计的多视图方法与软件架构设计的多视图方法做类比。
《方案书》意味着架构师在一个项目中需要进行对已经“明确”的架构进行更进一步的细节架构，即RA阶段。前边说明的“明确”的架构就是《方案书》中所说的方案，这里引用书中原文的几句话“方案=项目+需求+架构的总览，而方案≠架构的全部”，小张没有将“架构”进行细化，所以他的任务不算完成。
那么什么是软件架构呢？架构对应英文单词“Architecture”，在英文里Architecture是个名词，表示结构。但实际上结构只是架构的产物，如何得到这个结构呢？是通过架构师的一个个决策得到的。所以，架构包含了过程和结果，其过程就是项目所有人员共同完成的一部分，然后架构师根据所有的成员完成的任务，以及项目、需求综合起来形成的一个结果。这就是我所理解的软件架构。它是一个有机的结合，靠着一个项目的所有人员共同完成的一项结果。
从那本书中，我截下了这个图
这是RA阶段中的细化架构与概念架构的分层及比例，明显的可以看出细化架构处于概念架构和开发实现之间，所以项目的实现之前必须进行细化架构，细化架构就是项目的实现阶段，让项目的所有人员将概念转换成实现的一个重要的步骤。
逻辑架构在书中解释为划分子系统，定义接口等等属于逻辑架构的工作。
划分子系统的方法有三个：①分层的细化；②分区的引入；③机制的提取；
这三点老师都在课堂上讲到过，详细的示例在网络上都可以找到，这里我找到了一篇关于划分子系统的博客，贴在了帖子内
https://www.cnblogs.com/riasky/p/3476592.html
在使用这种方法后，很想找到一种新的名词来代替“子系统”，因为很多人提到子系统的时候很可能想的都是前台界面和后台逻辑的划分，而最大尺度上的非功能分割。
关于物理架构、运行架构以及开发架构（转载于原文链接：https://blog.csdn.net/cui841923894/article/details/84677805）
物理架构
为什么需要物理结构设计
有时候增加硬件未必能解决问题；
软件实际服务能力不仅受到“硬件资源”的制约，也受到“数据短缺”和“数据争用”的制约。
增加硬件 = 增加计算能力 不等于 软件的实际服务能力增强
物理结构关注如何可以满足软件系统的可靠性、可伸缩性、持续可用性、性能、安全性等方面的要求。
物理架构设计的工作内容
物理架构设计主要的3项任务：
硬件选择和物理拓扑。
软件到硬件的映射关系。
方案的优化。
物理架构的设计思维
从设计结果层面，决策无非围绕物理节点、网络、软件单元、数据单元等内容展开。
运行架构
为什么需要运行架构设计
当系统并不引入任何并行或并发处理，并且也没有给予SDK、API等基础软件进行定制开发，那就不需要设计运行架构设计。
如果系统为了应对复杂的业务逻辑或者复杂的互操作逻辑（含硬件交互），或者为了优化关键资源使用效率，而必须借助多条控制流并行或者并发执行时，就需要设计运行架构。
运行架构设计工作内容
运行架构设计可能根据具体情况不同包括下列工作内容:
确定引入哪些控制流。
确定每条控制流的任务。
处理相关问题：控制流的创建、销毁、通信机制等。
进一步考虑：控制流之间的同步关系，若有资源争用还要引入加锁机制。
控制流图是关键。运行架构设计的工作看似多而杂，单其实只要把握“控制流图”，就能够提纲挈领地开展其他相关设计。
实现控制流的3种常见手段
最常用于实现控制流的3种手段：
进程、线程、中断服务程序。
开发架构
为什么开发架构是必须的
并行开发所需的“程序单元”、“源码目录结构”等概念，是不同程序团队开展具体工作的基础。
能支持并行的详细设计。
让程序经理参与到架构实践的工作，免去大量的“单纯架构交流”的工作量，更让程序人员有“成就感”。
开发架构设计的工作内容
一般完成：
1.将“逻辑职责”映射为“程序单元”：
要自主编写的源程序
可重用的库、框架
其他方式（如shell脚本、平台支持下的配置文件）
2.开发技术选型
开发语言
开发工具
3.“程序单元”间的关系
Project划分
Project目录结构
编译依赖关系
重用测试是关键
解决年复一年修复类似问题的问题
从根本上降低维护成本