对比
MapleSpire 与 Structurizr：哪一个更适合企业级治理？
Structurizr 和 MapleSpire 都建立在 C4 模型之上，都是真正的模型，而不是图画。它们的分歧在于一个对大型组织至关重要的问题：共享元数据存放在哪里，以及谁能让它保持最新。
当架构就是代码、由工程团队在 Git 中编写和评审时，Structurizr 表现出色。MapleSpire 的目标是一个受治理的知识库：整个组织只有一套标签和技术目录，凡有权限的人都能以可视化方式编辑。
两种建模理念
Structurizr 是一款“模型即代码”工具：架构用文本 DSL 编写，在 Git 中进行版本管理，再推送到服务器生成图表。其文档建议每个软件系统一个 workspace，由构建该系统的团队负责。
MapleSpire 是一个共享的可视化模型：对象、关系和视图保存在数据库中，可以多人实时协作编辑，离线时依然可用。标签和技术目录是组织级实体，而不是复制到每个文件里的文本。
抽象地说，两种方式并无优劣之分。差异会在团队、系统和贡献者数量增长时显现出来。
分配元数据：标签、技术、版本、分组
| 元数据 | Structurizr | MapleSpire |
|---|---|---|
| 标签 | 每个元素自由填写文本（tags "A,B"）；样式绑定到标签文本 | 标签和标签组在组织层面定义一次，按 ID 引用 |
| 重命名或合并标签 | 在每个 workspace 中查找替换 | 重命名、改色、合并或归档：处处生效，覆盖所有架构全景 |
| 技术 | 自由文本（technology "Java"） | 受管理的目录：别名、浅色和深色图标、文档链接 |
| 技术生命周期 | 未建模 | 启用、弃用、淘汰或合并；新增条目需经审批 |
| 所用版本 | 需自行写进文本或 properties | 每次使用技术时都会记录所用版本 |
| 分组与领域 | 在 DSL 中声明的可视化分组 | 可承载标签和技术的分组；层级化领域 |
| 自定义属性 | properties 和 perspectives（自由键值对） | 模型中已规划，界面中尚不可编辑 |
在 Structurizr 中，用 tags、technology、properties 和 perspectives 关键字描述元素。它们都是自由字符串，需要逐个元素输入。archetypes 提供默认值，样式挂接在标签上，但没有一个中央注册表来定义什么是有效的标签或技术。
实际上，“PostgreSQL”“Postgres”和“postgresql 16”可能同时出现在不同的 workspace 中。重命名一个标签意味着要在所有相关仓库中查找替换，也没有任何机制阻止有人使用组织已经淘汰的技术。
在 MapleSpire 中，对象不保存标签文本，而是保存对一个在组织层面只定义一次的标签的引用。技术来自受管理的目录，带有别名、图标和生命周期。
负责人呢？
归属关系（哪个团队对某个元素负责）往往是治理流程要求的第一项元数据。在 Structurizr 中，它只能写进一个自由属性，例如 owner 键，与团队目录没有任何关联。
MapleSpire 已经为访问控制管理团队，其模型也计划为对象分配负责团队。不过这一分配功能尚未在界面中提供：与其许诺，我们更愿意如实说明。
更新一次，人人生效
对于企业视图，Structurizr 建议分三步走：把软件系统汇总到一个通过 URL 共享的 DSL 目录中，让每个团队的 workspace 扩展该目录，再生成整体架构全景。这个全景由管理员拉取所有 workspace、运行生成器并推送结果而得到。它是一份副本：后续变更需要重新生成才能体现。
在 MapleSpire 中，标签和技术保存在组织的数据库里。在管理控制台中做出的修改会立即体现在所有架构全景中，无需发布步骤。在同一个架构全景内，每个对象只存在一次，每张图都引用它。
为准确起见，有两点需要说明。在 MapleSpire 中，详细模型仍以每个架构全景为范围，只有目录在整个组织内共享。此外，每次技术使用都会保留录入时的目录版本，因此目录的修改绝不会悄悄改写历史。
访问控制与变更评审
Structurizr server 的开源核心没有身份验证，也没有基于角色的访问控制：workspace 是公开的。角色、SAML、LDAP 和管理 API 随授权的预构建二进制文件提供。它的强项在别处：由于模型就是代码，每次变更都可以经过 pull request、评审以及 CI 中的自动校验。
MapleSpire 的 AGPL-3.0 代码包含组织角色、按架构全景授予读写权限的团队、基于 Google 或 Microsoft 的 OIDC 单点登录，以及管理操作的审计日志。变更在草稿中准备，附带变更清单，并通过能检测冲突的合并完成。
当前的限制：MapleSpire 的草稿在合并前还没有正式的审批步骤。如果你的治理要求每次变更都必须经过评审，那么目前 Structurizr 的 pull request 流程更严格。
哪一个扩展性更好？
| 标准 | Structurizr | MapleSpire |
|---|---|---|
| 跨团队术语一致 | 取决于纪律和评审 | 由唯一目录强制保证 |
| 非开发人员参与 | 需要学习 DSL 和 Git | 可视化、多人、实时编辑 |
| 最新的全局视图 | 按需重新生成全景 | 实时共享目录；详细模型按架构全景划分 |
| 强制变更评审 | pull request 与 CI | 草稿与合并，暂无正式审批 |
| 访问控制与 SSO | 授权二进制文件 | 包含在开源代码中 |
| 高可用 | 取决于所选存储和许可证 | 同步目前以单实例运行 |
如果你的挑战是让整个组织说同一种语言（相同的标签、技术和版本），并让架构师、产品负责人以及不常使用 Git 的团队参与进来，那么在治理层面 MapleSpire 的扩展性更好。
如果你的架构已经以代码方式管理，贡献者都是开发人员，治理通过 pull request 评审进行，那么 Structurizr 依然是出色的选择。
迁移，或两者并用
MapleSpire 可以导入 Structurizr DSL workspace 并生成相应的 C4 图表，也可以导出为 Structurizr DSL、Mermaid、JSON、CSV、SVG、PNG 和 Markdown。因此，你可以在现有 workspace 上试用 MapleSpire，而无需放弃原有文件。
资料来源
关于 Structurizr 的说明基于其官方文档，查阅于 2026年10月12日。本文所述的 MapleSpire 功能均来自已发布的代码。