从需求到细化架构规格的系统思考链路

程序员向架构师转型的关键突破是学会系统思考——一种”见树又见林”的艺术，要求从关注局部转向纵观整体、从事物表面转向洞察背后的结构。架构设计的依据是需求，但从需求到设计跨度很大、涉及面很广，架构设计师必须是系统思考者，才能理清这条完整链路。从需求分析到概念架构设计：需求分析活动要明确功能、质量、约束三方面的需求（连同领域模型一起并称为”需求成果”），确定关键需求活动进一步从中提炼出关键功能和关键质量，概念架构设计则以这些关键需求为输入、产出概念架构——关键需求和概念架构合称”高层架构成果”，这正是投标时讲”解决方案建议”的重点内容。从概念架构到细化架构设计，输入来源有三条，且每一条都揭示了一层重要的约束关系。一，概念架构本身是细化架构设计的输入——如果概念架构确定了C/S架构风格，细化架构不能”不管不顾”直接搞成B/S风格，这条约束保证了架构决策的连贯性。二，各种”需求”是细化架构设计的输入——这里有个关键对比：概念架构设计依据的是”关键需求”（一个精选子集），而细化架构设计依据的是”（所有）需求”，这个从”精选子集”到”全集”的转变，正是概念架构到细化架构在需求覆盖广度上的本质区别。三，”领域模型”是细化架构设计的输入——一个采用分层架构的系统，除了UI层、数据层、集成层，通常会有业务层或领域层，细化架构设计时要参考之前定义的领域模型，把领域层内的核心模型用选定的编程语言明确定义下来。

结构图：

flowchart LR
    A["需求分析\n功能+质量+约束"] --> B["确定关键需求\n关键功能+关键质量"]
    B --> C["概念架构设计"]
    A -.->|"领域模型"| D["细化架构设计"]
    C -->|"架构风格连贯性约束"| D
    A -->|"所有需求（非仅关键需求）"| D