首先什么是Pre-architecture？
Pre-architecture就是架构设计的最前期阶段，其工作目标包括：理解需求、建立需求大局观、确定架构设计方向等。
一名软件架构师，需要理解的大局观，是有效处理互相矛盾的需求目标；识别重大需求、特色需求、高风险需求；在相对短的时间内设计出一套正确且有效的架构等等。不仅需建立需求大局观还要学会降低架构失败风险，因为作为架构师，我们往往在需求的理解、权衡、取舍和补充这些方面能力严重不足。从概念架构到细化架构，先设计概念架构，构思关键问题的解决策略；再进行细化架构的设计，以保证为开发提供足够的指导和限制。简单理解，细化架构就是分割，将大问题化成小问题，将概念架构中的设计进行实现，概念架构难以支持并行开发，所以要有细化架构的过程，将概念具体化，用代码进行实现，细化架构和概念架构之间的典型差异。
架构设计仅仅进行到概念架构层面，对支持团队的并行开发而言是远远不够的。书中有这样一个例子，在《方案书》确定之后，架构师觉得方案书被认可说明架构已经很明确，无需“再”架构，但是程序员并没有在实际开发中得到足够的指导和限制，这就是在第一个名言中所描述的“项目的系统架构尚未确定”，及概念架构之后没有进行深一层次的“规约”设计，及细化架构，细化架构及概念架构的区别如下表。
|
细化架构
|
概念架构
|
|
|
接口
|
核心地位
|
不关心明确的接口定义，只有抽象的组件和抽象的交互机制
|
|
子系统
|
通过子系统和模块来分割整个系统，并且子系统往往有明确的接口
|
只有抽象的组件，这些组件没有接口，只有职责，一般是处理组件、数据组件或连接组件中的一种。（有大组件分解成小组件的设计决策，非子系统的含义）
|
|
交互机制
|
“实在”的交互机制，如基于接口编程、消息机制或远程方法调用
|
概念化的
|
在做任何架构设计时都要记住尽早开始架构设计，Pre-architecture阶段的好处：能够在需求没有“全面完成”的情况下开始架构设计。为了尽早开始架构设计，需要做好：让架构师参与需求分析工作；不能被动地等待完善的《软件需求规则说明书》出现的那一刻。在只要满足下面3个条件就可以开始架构设计工作：
（1）有了明确的业务需求：必须保证甲、乙双方就建设系统的目标达成共识，《愿景文档》经过正式评审，并且明确了投资、工期标准、整合等约束条件；
（2）了解全面的用户需求：系统能帮助用户干什么、不能干什么已经非常明确。如果采用用例技术，表现为“用例图”比较完善，没明显遗漏；
（3）有了典型的行为需求；如果采用用例技术，表现为核心功能的《用例约束》已经定义。
确定关键质量目标意义是：指定错误的质量属性目标（包括遗漏重要的质量属性），将面临客户不满、项目返工、同事抱怨……而确定关键质量主要完成以下两点：
（1）根据系统所在领域的特点及系统规模等因素，确定架构设计重点支持哪些质量属性（例如高性能、可扩展性…）
（2）分析上述质量属性之间的制约关系，第一时间指定权衡折衷的具体策略（例如明确高性能是第一位，可扩展性和高性能相矛盾时应照顾高性能要求，是否引入支持可扩展性的涉及需经过架构组评审）
确定关键质量我们必须遵守的5大原则：
（1）分类合适+必要扩充
（2）考虑多方涉众
（3）检查性思维
（4）识别矛盾+划定优先级
（5）严格程度符合领域和规模特点
划分子系统的三种方法：
（1）分层的细化
（2）分区的引入（架构中引入分区，支持深度优先的迭代开发）
（3）机制的提取（基于接口（或抽象类）的协作是机制，基于具体类的协作则算不上机制；实现不同的最终功能可以重用同一个机制），及“总-分-总”
简单理解，细化架构就是分割，将大问题化成小问题，将概念架构中的设计进行实现，概念架构难以支持并行开发，所以要有细化架构的过程，将概念具体化，用代码进行实现，细化架构和概念架构之间的典型差异。
