架构落地四阶段：模型类型的分布规律

架构落地方法的四个阶段——需求分析、架构设计、系统实现、系统维护——上一阶段的输出是下一阶段的输入，且每个阶段偏重使用的[[系统描述的三种维度：功能、结构、行为|模型类型]]呈现出明显的规律。需求分析阶段主要关注系统能提供哪些功能，此时系统更像一个黑盒，产出的模型以功能模型为主（价值链/价值流、服务蓝图），同时会产出上下文图（结构模型，界定系统范围边界）和业务流程（行为模型）。架构设计阶段需要逐步打开需求分析阶段留下的这个”黑盒”，填入具体内容去支撑各种功能，因此这个阶段的模型基本转向结构模型和行为模型——应用分层架构图、应用交互图是结构模型，业务场景图是行为模型；这个转变背后的逻辑是：需求分析阶段回答的是”要不要、需要什么功能”，一旦定了功能范围，接下来自然要回答”这些功能靠什么结构、什么样的行为链路去实现”。系统实现阶段要把架构设计阶段的概念模型做物理实现，常用类图、时序图，同样属于结构和行为模型的范畴，只是相比架构设计阶段的模型更加微观化——从”应用之间怎么交互”细化到”类之间怎么调用”。系统维护阶段由于持续新增功能或维护存量功能，实际上会重新用到前三个阶段的全部模型类型，而非产出一套全新的模型。可迁移启发：判断一份架构文档”该有什么内容”时，可以先确认它属于四阶段中的哪一个——如果是需求分析阶段的文档却充斥着结构/行为模型的细节，很可能是过早地把黑盒打开了；反过来，如果架构设计阶段的文档仍然只停留在功能模型层面，说明这个”黑盒”还没有真正被打开。