租赁系统确认了一笔预留，不代表租赁、维修与结算已经形成一致的企业能力。维修状态可能来自人工登记，结算口径可能独立维护，系统名称相同也可能指向不同责任边界。讨论企业架构时，先把当前事实与目标状态分开，才有可能判断迁移缺少什么。

本系列的现状很小：第 38 篇运行一个 JVM，真实回环 HTTP 进入租赁用例，仓储是内存对象，维修查询是固定的进程内实现，结算应用尚不存在。本篇以这份现状设计租赁、维修、结算三个目标应用，建立带类型的关系图和迁移约束。目标部署全部为 NOT_RUN，实验只验证有限模型规则。

方法、语言与分类框架不能混用

TOGAF 第十版提供企业架构方法与相关指导。本篇采用 ADM 的业务、信息系统、技术架构以及机会方案、迁移规划这些阶段概念来整理问题，不把一次教学建模称为完整 ADM 项目。没有组织治理、利益相关方授权和真实迁移活动，就不能声称企业已经完成架构转型。

ArchiMate 用建模语言表达业务、应用和技术等元素及关系。它可以为 ADM 产生的描述提供表达方式，但不会替团队决定业务目标、预算和迁移顺序。本实验固定为三点二版的有限类型子集，只检查选定的应用组件、应用功能、应用服务和业务过程之间的三类关系。

Zachman 框架将企业描述按问题维度和不同层次组织。官方简明定义强调它是本体分类框架，不是项目方法。本篇用 What、How、Where、Who、When、Why 检查信息遗漏，同时讨论从识别到实例化的不同描述层次，不把一张六列清单宣称为已经填满整个矩阵。

这三者放在一起，是为了分别处理推进活动、表达关系与检查描述维度。若只更换图标，业务目标与代码之间的断裂依然存在；若把分类单元格当成迁移步骤，又会误以为从左到右填完表格就完成了实施。每种工具的用途都需要明确限定。

当前实现究竟提供了哪些能力

当前租赁入口能够接受受限请求号，执行固定设备和租期的预留，处理同请求号重放，并拒绝非法输入。第 38 篇的真实实验支持这些局部行为，不能据此推断存在设备全生命周期管理、账单核销或生产客户接入。

维修查询是调用一个固定可用性函数，不存在独立维修系统，也没有远程超时、维修单流转和授权校验。把它画成已经部署的维修服务，会把未来集成成本隐藏起来。现状模型因此明确标注 in-process，并把“独立维修应用”放在目标区。

结算更加需要区分：当前代码没有结算应用。目标模型可以提出计费、应收与退款相关能力，但不得把这些标签解释成现有接口。财务规则本身也没有经过业务确认，本篇只使用教学假设来说明责任与依赖，不能替代真实会计或税务设计。

现状还包含一个重要技术约束：内存仓储不提供进程退出后的持久化恢复。目标三应用如果要交换可恢复的业务事实，必须补上状态持久化、跨边界身份及可靠传递。模型中记录这些差距，比把当前单体分成三个彩色方框更有助于评审。

从业务目标推导责任边界

教学目标设为减少租赁确认与维修状态不一致，并让结算能够依据已确认事实生成一致结果。这个目标需要可观察结果，而不是“实现微服务化”这样的技术动作。是否拆进程、是否引入消息都应服务于目标，并受运维能力和故障成本约束。

租赁应用负责合同与预留状态，维修应用负责设备维修状态及可租判断依据，结算应用负责自己的结算结果和对外解释。所有权不是代码目录名，而是发生冲突时由谁定义状态含义、批准变化并提供修复流程。教学模型使用 rental、maintenance、settlement 作为角色假设。

共享设备身份与业务事实格式必须先形成契约。租赁与维修都使用设备编号，不代表它们共享同一状态机；维修完成和租赁可预留之间也可能存在时间窗口。契约需要说明消息含义、发生时间、版本、重复处理和无法确认时的行为，不能只规定字段长度。

下面是目标关系图，目标框中所有应用均未独立部署。箭头描述计划中的服务协作，不是已经抓到的网络流量。它说明租赁依赖维修判断，结算依赖租赁确认事实；具体同步或异步协议仍需要后续实验选择。

flowchart LR
  subgraph T["目标：三个独立应用，全部NOT_RUN"]
    R["租赁应用：合同与预留"] -->|可租判断契约| M["维修应用：设备维修状态"]
    R -->|确认事实契约| S["结算应用：结算结果"]
  end
  C["现状：单JVM、内存仓储、固定维修函数"] -.差距与迁移.-> T

企业级边界也不保证运行级隔离。目标模型给出了不同节点名，但尚未创建进程、端口或数据库，节点只是部署意图。故障隔离、网络身份和独立发布都要由实际运行证明；graph checker 通过不能替代这些证据。

有类型的关系比无名箭头更容易审阅

每个目标应用拥有四个元素：ApplicationComponent、ApplicationFunction、ApplicationService、BusinessProcess。组件承担功能，功能实现对外服务，服务支持业务过程。三种关系分别使用 assignment、realization、serving，并按本实验的允许三元组检查方向与端点类型。

这个子集参考 Open Group 官方中文三点二参考卡中的元素和关系定义。完整规范页面当前跳转登录，本文没有读取其全部关系规则，也没有实现派生关系、视点约束或交换格式验证。因此“符合本实验子集”与“完整 ArchiMate 模型符合性”必须分开表述。

普通流程箭头往往只写一个动词，却混合了责任、实现和服务消费。明确关系类型之后，评审者能问出更具体的问题：哪个组件承担功能，哪个功能实现服务，哪个业务过程消费服务。回答这些问题仍需要业务判断，类型检查只负责避免明显的类别混用。

错误样本把组件到功能的 assignment 改成 serving。两个端点仍然存在，图也仍然连通，但它不满足本实验允许的三元组，因此检查器退出一。这比只检查“所有箭头都能找到终点”更有区分力，也说明图能画出来不等于语义约束成立。

另外一份错误样本把关系终点改成不存在的身份，同样独立拒绝。稳定身份使跨图引用不会依赖展示名称；名称可以随业务术语调整，但变更身份会影响关系、迁移计划与证据索引，需要同步处理。

迁移次序来自依赖与退出条件

迁移模型包含契约、维修、结算、切换四步。先约定身份与交互语义，再让维修边界具备实现条件，随后接入结算，最后决定是否切换目标路径。这个次序是教学选择，不是 TOGAF 强制要求所有企业都按同一顺序实施。

每一步记录 owner、risk、exit_evidence 与 depends_on。契约步骤的退出条件应包括可执行兼容性样本；维修步骤需要故障与恢复证据；结算步骤需要重复事实处理及对账；切换步骤需要回退和监测结果。这些都还没有实际运行，因此迁移状态保留 NOT_RUN。

下图说明依赖检查的含义。箭头只表示某步的前置条件，不能解释成日历工期或已经完成的项目进度。四个节点均需要独立证据才能从计划进入已执行状态。

flowchart LR
  C["契约：身份、版本、业务语义"] --> M["维修：独立状态与故障实验"]
  M --> S["结算：重复处理与对账"]
  S --> X["切换：监测、恢复与回退"]

检查器按照列表顺序逐步累计已经出现的步骤，要求当前步骤的依赖都在前面。逆序样本因此退出一。它没有估算人员容量、预算、关键路径或真实完成日期，不能因为拓扑顺序正确就宣称迁移可按期交付。

风险需要与具体差距相连。维修服务不可达时租赁如何处理，结算消费重复事实时如何避免重复记账，切换失败后旧路径是否仍有一致数据，都不是填写“风险可控”能够解决的问题。计划应保留责任人角色和所需证据，让下一次实现有清楚的验收入口。

Zachman 的六个问题如何发现遗漏

What 对应设备、合同、维修状态和结算事实的身份与定义。How 对应确认、维修判断和结算处理的行为。Where 记录现状本机与目标节点，并严格区分部署意图和运行事实。Who 指出状态与契约的责任角色，When 说明确认、维修变化及结算触发的时点，Why 写明减少不一致的业务目标。

模型还需要区分描述层次。业务层的“设备不可租”是业务概念，设计层可以把它表达为服务结果，技术层才选择字段、协议与存储，运行实例层则需要具体消息或请求证据。把同一个词在不同层次重复六次，并不能建立这些转换关系。

本实验没有构建完整六乘六矩阵，也没有验证每个单元格的框架定义。它只检查六类问题都有非空回答，作为有限的遗漏提示。官方框架图具有版权声明，本文使用自己的租赁关系图，不复制官方矩阵图来制造正式认证的视觉印象。

六问清单仍可能通过得过于容易。比如每个字段都填“待定”，形式上非空，实际没有帮助。因此自动检查结果之外，还要读内容是否回答了当前问题、是否把假设标明、是否与现状源码冲突。有限检查器的价值是减少机械错误，不能替代企业架构判断。

实验结果与独立运行

1
bash examples/software-modeling/labs/E11/run.sh

正常模型通过九条类型关系和四步迁移顺序检查。四份反例分别验证错误关系类型、逆序依赖、未知端点以及把未运行目标写成 VERIFIED_LOCAL。每份反例使用同一程序独立运行，退出码一及断言原因保存在 evidence/E11，不能把示例表格当成这些失败已经发生的证据。

检查器读取第 38 篇源码确认当前基线入口和内存仓储描述存在，但 E11 不再启动目标应用，因为目标实现尚不存在。读者可在同一下载包中运行 E09，取得现状的真实 HTTP 轨迹；E11 的通过范围始终是有限图与迁移约束。

修改目标模型时，运行边界仍须保持诚实。可以新增未来数据库、消息代理与部署节点作为目标，但需要补充相应差距和验收实验。若希望宣称三应用独立部署，必须先实现和运行它们，采集请求、进程、存储及故障恢复证据，再修改模型状态。

企业架构对齐最终需要业务目标、责任与可运行能力相互对应。差距清单与受约束模型给出了后续实现入口。尚未完成的部分明确可见，评审可以据此区分概念连线与实际系统集成。

下载累计实验源码与证据

参考资料