阅读《软件架构实践第二版》---Refined Architecture阶段的理解

这一部分分为了五章来讲，

　　第一章：细化架构，

　　第二章：Refined Architecture总论，

　　第三章：逻辑架构，

　　第四章：物理架构，运行架构，开发架构，

　　第五章：数据架构的难点：数据分布。

这样的一个结构是根据每个阶段的先后顺序来讲的，在对一个系统进行架构开发时，我们需要先对其进行概念架构，然后是细化架构，最后开发实现。

 

 至于概念架构，作者在前几章已经进行了详细的描述。

在细化架构开篇，作者引入了两个小故事：

①《方案书》确认之后，通过这个故事带我们探究“方案”与“架构”的关系，点明了细化架构与概念架构之间的差异与联系。

细化架构与概念架构之间的差异表现在接口，子系统，交互机制等方面。方案与架构，相通之处在于他们都满足软件架构的定义——架构=组件+交互，架构=重要决策树。

最终告诉我们：

方案=“项目+需求+架构”的总览

方案≠架构的全部

②办公室里，争论正酣，告诉我们不同涉众看待软件架构的视角是不同的，贴近实践的多视图方法，应将一线架构师的各项具体工作涵盖其中。

 第二章里作者主要介绍了视图,首先点名视图不是阶段，其次指出视图包括RUP4RUP4+1视图（又称5视图），SEI3视图。其中五视图的结构如下所示：

 

 五视图包括用例视图，逻辑视图，开发视图，进程视图，物理视图，每个视图都是一组技术关注点。

 

 

第三章中，对五视图中的逻辑视图的逻辑架构进行了详细讲解，首先是划分子系统的三种必用策略：

*分层的细化，即将展现层，业务层，数据访问层，进一步细化

*分区的引入，分区的引入是为了解决“深度优先”开发的问题，分区是一个单元，较小的单位意味着它包含的功能就少，开发时所需要考虑的也就较少，更容易使深度优先开发实行。

*机制的提取，软件系统中的机制，是指预先定义好的、能够完成预期目标的、基于抽象角色的协作方式。机制不仅包含了协作关系，同时也包含了协作流程。首先我们要知道协作，协作是对象与对象的组合，可以这样说，机制便是基于对象的协作的组合。

这三者不是相互替代的关系，而是相辅相成的关系。

其次，探究划分子系统的四个原则：

*职责不同的单元划归不同的子系统

*通用性不同的单元划归不同的子系统

*需要不同开发技能的单元回归不同的子系统

*兼顾工作量的相对均衡，进一步切分相对较大的子系统

 

 开发接口时，要牢记“协作决定接口”。

 第四章讲的是关于物理架构的方面，首先点出：增加硬件=增加计算能力≠软件的实际服务能力增强。

物理架构主要有三方面：

*硬件选择与物理拓扑

*软件到硬件的映射关系

*方案的优化

 

 物理架构可以从两个方面理解：“攻”与“守”，这两个方面也很容易理解，物理方面基本就会涉及到资金，这样的话，就是要考虑让钱花的值，如何让钱花得值，那就是在能保证性能的前提下，物尽其用。

后面提到的开发架构与运行架构在很大程度上就是保证开发的严谨，开发的规范性。

最后一章讲的是数据架构，引用《SQL语言艺术》指出还是先给出数据结构的策略：

*独立Schema ( Separate schema)。

*集中(Centralized)。

*分区(Partitioned)。

*复制(Replicated)。

*子集(Subset)。

*重组(Reorganized )。

因为数据的重要性，所以首先要对数据进行复制备份，然后对数据高效利用，根据系统特点来决定是，分开存储，集中处理还是集中存储，分布访问。