架构意图的识别案例：功能系统与管理系统之别

[[办公系统案例识别分别无法得到真正的架构]]里的架构v0.0.0.1只是把办公室的日常功能按使用群体分了类（日常办公/电子化管理/特定业务），这本质上还是对现实系统事实的复制。作者展示了同一个办公系统的另一种架构v0.0.0.2：它引入了此前不存在的”业务集”（业务是某个未知规模集合的一部分，与特定用户无关）、”角色集”（规模未知，会随现实系统演化而扩展）和全新的”组织机构”（表达人与人之间的授权关系）三个概念，体现的是通过映射现实中的管理责权关系来规划系统，而非通过区分功能模块的适用群体——前者可以称为”办公功能系统”，后者应称为”办公管理系统”。关键在于”管理”这个概念从何而来：客户提出”办公系统”时，真实诉求往往只是减少手头工作、让流程更规范，从来不会主动提出”我需要一个有管理层次关系的角色体系”这种设定——这正是判断一个核心概念到底是来自现实系统的原始需求、还是来自架构师自己的设计意图的关键线索：如果是前者，那么控制这个概念的意义在于”控制原始需求”；如果是后者，控制的意义在于”控制设计欲望”。作者进一步指出，”管理”这个意图的产生有迹可循——回溯到”这一系统总是某些办公室成员使用的”这条最初事实，一旦意识到”办公室成员”可能是混合的、由不同工作需求交织而成的群体，这个系统本身就需要某种东西使自身规则化，”管理”由此才成为一个必要的架构设定，而非凭空捏造。可迁移启发：面对两份看起来都”正确”、但结构迥异的架构方案时，可以用这条线索去追问——每个核心概念是客户会主动说出口的原始需求，还是架构师主动命名、独立提炼出来的设计意图？前者应该被”控制”以贴合真实需求，后者应该被”控制”以避免架构师个人欲望的过度膨胀，两种”控制”的对象和分寸完全不同。

结构图：

flowchart TB
  A["同一个办公系统"]
  A --> V1["架构v0.0.0.1:办公功能系统<br/>按使用群体分类功能(日常办公/电子化管理/特定业务)<br/>=复制现实系统的事实"]
  A --> V2["架构v0.0.0.2:办公管理系统<br/>引入业务集/角色集/组织机构(人与人授权关系)<br/>=映射现实的管理责权关系(架构意图)"]
  V2 -.->|"客户不会主动提出'我需要管理层次关系'"| C["判断依据:概念来自原始需求(控制需求)<br/>还是来自架构师意图(控制设计欲望)"]