Daniel Hu的技术生活博客

一线架构师的6个经典困惑：

4个实际问题的困惑

• 将系统划分模块，如何更合理
• 大系统架构设计，如何起步？
• 总觉得需求很糟糕，影响了架构设计
• 非功能需求重要，但如何设计？
  

两个职业发展的困惑

• 架构新手：缺乏指导，架构设计不知所措
• 架构老手：缺乏总结，仍“怕”下一个项目
  

本书的四个核心主张：

• 方法体系是大趋势
• 质疑驱动的架构设计
• 多阶段方法
• 内置最佳实践的方法

质疑驱动的架构设计

架构设计实际上“质疑驱动的过程”：需求，被架构师的大脑（而不是自动）有节奏地引入架构设计一波一波的思维活动中。例如，架构到一半时，你可以明显感觉到：这个架构设计的中间成果，还须要进一步“质疑”引入更多“质量属性”，以及“特殊功能场景”来驱动后续架构设计的开展。

质疑意识，是架构师最宝贵的意识之一。

多阶段还是多仕途

架构设计的多视图方法很重要，但是架构设计方法首先应当多阶段，其次才是多视图的。一句话，先做后做——这叫阶段，齐头并进——这叫视图。

 

Pre-architecture阶段

Pre-architecture阶段的使命，可以概括为一句话：全面理解需求，从而把握需求特点，进而确定架构设计驱动力。

需求验证的目标是尽可能暴露问题，而不是证明无错。

架构设计不仅要求考虑支持功能、满足质量要求，还要重视各种约束性需求。关注约束，要趁早。

软件架构师不必是需求捕获的专家，也不必是《软件需求规则说明书》的专家；但他一定应在需求分类、需求折衷和需求变更的研究方面是专家，否则他和优秀架构师相比就输在了“起跑线”上。

Conceptual Architecture阶段

重大需求塑造概念架构。

Refined Architecture阶段

细化架构是相对于概念架构而言的。

面向对象或结构化——逻辑架构：职责划分、职责间协作

面向控制流——运行架构：控制流、控制流组织

面向文件——开发架构：程序单元、程序单元组织

面向Table或文件——数据架构：持久数据单元、数据存储格式

面向节点——物理架构：物理节点、物理节点拓扑

许多架构师，言架构必谈OO。在他们的思想里，认为OO方法已经完整涵盖了架构设计的所有方法和技巧，这种看法是相当片面的。

概念性架构就是对系统设计的最初设想，就是把最关键的设计要素和交互机制确定下来，然后考虑具体技术的运用、设计出实际架构。

概念性架构应该抓大局，不拘小节。

虽然概念性架构都跳不出“架构=组件+交互”的基本定义，但他们描述架构的具体方式还是有比较大的差异：有的重视逻辑层，有的重视物理层，有的通过隐喻表明机制，有的看上去似乎就是一些设计元素的组合。同步的概念性架构图中，“连接”代表的含义千差万别：有的依赖方向，有的依赖控制方向，有的是数据流向，因此必须根据具体情况而定。

概念性架构界定系统的高层组件，以及他们之间的关系。概念性架构意在对系统进行适当分解，而不陷入细节。借此，可以与管理人员、市场人员、用户等非技术人员交流架构。概念性架构规定了每个组件的非正式规约及架构图，但不涉及接口细节。根据定义，我们注意到如下几点：

• 概念架构满足“架构=组件+交互”的基本定义，只不过概念架构仅关注高层组件。
• 概念架构对高层组件的“职责”进行了笼统的界定，并给出了高层组件之间的相互关系。
• 概念架构不应涉及接口细节

概念视图，有时候称为“逻辑视图”，这种视图显示了系统的主要部分以及它们之间的相互关系。

如果只考虑“功能需求”来设计概念架构，将导致概念架构沦为“理想化架构”，这个脆弱的架构不久就会面临“大改”的压力。

从概念架构到细化架构，先设计概念架构，构思关键问题的解决策略，再进行细化架构的设计，以保证为开发提供足够的指导和限制……这符合人类解决问题的规律，因此被广泛采用。

细化架构和概念架构之间存在如下典型的差异：

• 接口。在细化架构中，接口占据非常的地位，而概念架构并不关心明确的接口定义（只有抽象的组件和抽象的交互机制）
• 子系统。细化架构重视通过子系统和模块来分割整个系统，并且子系统往往有明确的接口；而概 念架构中只有抽象的组件，这些组件没有接口，而只有职责，一般是处理组件、数据组件或者连接组件中的一种。当然，概念架构中也有“大组件分解成小组件”的设计决策，但不是子系统的含义。
• 交互机制。细化架构中的交互机制应是“实在”的，如基于接口编程、消息机制或者远程方法调用等；而概念架构中的交互机制是“概念化”的，例如“A层使用B层的服务”就是一个典型的例子，这里的“使用”到了细化架构中可能基于接口编程、消息机制或者远程方法调用中一种。