什么是架构？为什莫要进行架构？怎样进行架构？这三个问题基本可以涵盖本书全部内容。为什莫我会如此大胆的说——因为这三个问题已经包含了架构的意思，有边界，有层次，分工明确，这些部分之间能够进行有机的联系，合并组装成为一个整体，完成目标的所有工作。这是我对全书的概念与认知路线，下面对第三部分Refined Architecture阶段进行探讨：
对于什么是架构？每个角色都有自己的关注点，不同涉众看待软件架构的视角自然也是不同的。不过也不是无迹可寻，大致可以从五个角度来划分：逻辑（职责划分） 物理（物理节点安排） 开发（程序单元组织） 数据（持久化设计） 运行（控制流组织）。也就是五视图，每个试图，一个思维，一组技术关注。这便是细化架构。
架构最重要的一点，就是它能把难以处理的大问题分解成便于管理的小问题。就划分子系统策略，可归纳为3种：
分层的细化：可简单地概括为MVC模式，模型(model)－视图(view)－控制器(controller)，它们各自处理自己的任务
分区的引入：引入分区，以便于支持深度优先的迭代开发
机制的提取：基于具体类的协作则算不上机制、基于具体类的协作则算不上机制、基于接口（或抽象类）的协作是机
制，实现不同的最终功能可以重用同一个机制。
而划分子系统的依据4个重要原则：
职责不同的单元划归不同子系统
通用性不同的单元划归不同子系统
需要不同开发技能的单元划归不同子系统
坚固工作量的相对均衡，进一步切分太大的子系统
协作决定接口，"分"是手段，"合"是目的，不能合在一起支持更高层次功能的模块，有何用？
设计模式是基础，要站在各个角度看软件架构。并且通过质疑“对不对”和“好不好”，可以发现新职责，或者调整协作方式。
逻辑架构设计的整体思维便是质疑驱动
结构设计和行为设计相分离。
架构设计不是一蹴而就。需求对架构设计有“驱动”作用，不断设计中间成果->质疑中间成果->不断调整完善细化中间成果->继续质疑->继续完善…
物理架构思维框架：目标层(XX性)，思维层(XX开销，xx争用)，结果层(软件单元, 数据单元, 物理节点, 网络)
运行架构：如果系统中没有引入并行处理或者并发处理，并且系统也没有基于sdk，api等基础软件进行定制开发，那就不许要运行架构
运行架构包括：1，控制流(进程线程，中断的服务)2，控制流组织(系统启动停机 控制流通信 加锁或者同步)
确定引入控制流的几点建议：为了实现节点之间的通信，通常的做法是引入一条控制流来专门负责，物理架构中每个节点至少有一个控制流，节点是具有主动行为的设备，并为其引入专门的控制流，来自用户或者外部系统的并发访问，常需要后端服务支持多控制流。在需求一级描述的并发或者并行的也需要引入控制流
一单系统中不止一条控制流，则需要附加工作量(创建 销毁 建立共享内存 消息)等不同工作量直接的通信机制
控制流：是再一个处理机上顺序执行的系列动作。控制流图显示了系统中不同控制流之间的关系，控制流的起点是主动单元，它会调用被动单元，如此层层调用，就形成了一个控制流。明确了系统中所有的主动单元，就抓住了每个控制流的源头，从而可以把并发执行的所有控制流程理清楚。
运行架构设计工作只要把握住控制流图，就能提纲挈领的开着其它设计工作
控制流的常用手段：进程 线程 中断的服务