1.细化架构是相对于概念架构而言的，而架构设计仅仅进行到概念架构层面，对支持团队的并行开发而言是远远不够的。常见的错误就是把《方案书》中的概念架构设计部分直接作为《架构设计文档》提交。
2.谈到架构，必须先说一下OO，即Object Oriented（面向对象），面向对象是软件开发方法，面向对象的概念和应用已超越了程序设计和软件开发，扩展到如数据库系统、交互式界面、应用结构、应用平台、分布式系统、网络管理结构结构、CAD技术、人工智能等领域。但是OO依旧只是软件开发方法，而并不是软件架构方法，不能完全涵盖软件架构方法。
如下图，软件架构5视图所涉及的逻辑架构、物理架构（面向节点）、开发架构（面向文件）、运行架构（面向控制流）、数据架构（面向Table/文件）并没有全面受到OO方法的指导。
3.架构设计是一门解决复杂问题的实践艺术，所以，分而治之的思想必不可少，分而治之，目的是“治”而不是“分”。而分而治之中“多视图方法”又恰恰支持细化架构。现代系统非常复杂，很难一下领会。相反，在任何时刻，我们只能把注意力放在软件系统的一个或几个结构上。为了有意义地传达架构的信息，必须说明此刻正在讨论哪个或哪些结构——即采用的是架构的哪个视图。
所以，多视图方法有两个方面的实际意义:
#利于思考（因为分而治之的思维方式）。
#便于交流（因为在一定程度上分离了涉众关注点）。
4.一线架构师最缺的不是理论， 也不是技术，而是位于理论和技术之间的“实践策略”和“实践套路”。
——一线架构师实践指南
划分子系统的实践策略可归纳为3种：分层（Layer）细化，分区（Partition）引入，机制提取。这里要注意的是，为了支持迭代开发逻辑架构设计中必须引入分区。
机制的定义：软件系统中的机制，是指预先定义好的、能够完成预期目标的、基于抽象角色的协作方式，同事也包含了协作流程。基于接口(和抽象类)的协作是机制，基于具体类的
协作则算不上机制。
逻辑架构的整体思维套路要点：1.质疑驱动；2.结构设计和行为设计相分离。
5.增加硬件 = 增加计算能力 ≠ 软件的实际服务能力增强
计算与计算往往不是孤立的，它们之间存在着复杂的“生产者——消费者”关系，所以软件的实际服务能力不仅受到“硬件资源”的制约，也受到“数据短缺”和“数据争用”的制约。
6.物理架构设计主要有三项任务：
#硬件选择与物理拓扑
#软件到硬件的映射关系
#方案的优化
7.数据架构的难点：数据分布
确定数据分布方案是数据架构设计的难点。越是大系统，数据分布越关键。因此，一线架构师迫切须要建立数据分布策略的大局观。
数据分布的6种策略：独立、集中、分区、复制、子集、重组。如下图
#非复制方式包括3种具体策略:集中、分区、独立Schema。
#复制方式也包括3种具体策略:复制、子集、重组。
###以上就是我阅读《一线架构师实践指南》一书的有关总结与一些想法。