架构形成模型M0的层次约束链条

系统架构的”内部实现”过程——架构各部件如何被构建、维护并相互约束——可以用一个参考模型M0来刻画：宏观规划层约束需求映射层，功能架构约束开发架构，能力架构映射为实现架构时不能丢失功能设计，开发实现的结果必须能被应用于预设的交付环境。作者把这个抽象过程落到一个具体案例上，拆成四个层次：功能层（不需要过深讨论，是从此前功能架构逐步细化而来，基本映射用户的原始需求）；服务层（用静态的运行架构表达，把功能包装并发布成服务，比如”角色定义服务”是对角色集的封装、”业务登记服务”是对功能集的封装，约束了开发架构里包的组织与接口设计）；框架层（是更高层级的架构决策，用动态的运行架构表达，决定功能运行在什么环境里、服务之间的结构关系、乃至用户与系统打交道的接口方式，约束了可选的第三方应用服务器以及必须自主开发的关键联接件）；产品层（依赖集成架构表达，把可运行框架封装交付成”产品”，约束部署架构可用的部件及其组合依赖关系——真正的系统集成不是简单地把代码包build起来，而是让代码包与运行环境、数据库这些外部产品配合无间）。这四层构成一条自上而下逐级收窄、自下而上逐级支撑的约束链条：每一层的架构决策都在为下一层划定边界，同时每一层的实现质量又决定了上一层的意图能否真正落地。可迁移启发：审视一份系统架构是否完整，可以检查它有没有说清楚”功能→服务→框架→产品”这条链条上每一环对下一环构成了什么具体约束——只谈功能不谈服务封装方式、只谈框架选型不谈它如何被集成交付成产品，都意味着这条约束链条在某处断裂，架构决策的影响力传不到最终的开发与部署环节。

结构图：

flowchart TB
  A["功能层<br/>映射用户原始需求(功能架构)"]
  A -->|"约束"| B["服务层<br/>功能封装发布成服务(静态运行架构)<br/>如角色定义服务/业务登记服务"]
  B -->|"约束"| C["框架层<br/>驱动服务与功能的整体方式(动态运行架构)<br/>决定运行环境/服务间结构/用户接口"]
  C -->|"约束"| D["产品层<br/>封装可运行框架交付成产品(集成架构)<br/>约束部署可用部件及组合依赖关系"]