用Schema约束架构 ── 让人类与AI在同一规则下运行

はじめに
前言
こんにちは、ZOZOTOWN開発1部iOSブロックの@kitasukeです。
大家好,我是ZOZOTOWN开发1部iOS组的@kitasuke。
前回の記事「ZOZOTOWN iOS のアーキテクチャとチームの進化」では、MVCからMVVM、そしてMVVM + Repositoryへのアーキテクチャ進化を取り上げました。あわせて、レビュー文化をチームに根づかせてきた3年間も振り返っています。
在上一篇文章“ZOZOTOWN iOS的架构与团队的进化”中,我们介绍了从MVC到MVVM,再到MVVM + Repository的架构演进。同时,我们也回顾了将review文化扎根于团队的这3年。
ただ、アーキテクチャを文章で定義しても、書き手によって命名や責務分割はぶれが生じますし、AIに任せると過去の望ましくない実装パターンまで律儀に再現されます。ドキュメントによる「努力目標」では、アーキテクチャは守りきれません。
不过,即使通过文章来定义架构,不同编写者的命名和职责划分也会出现偏差,如果交给AI,它甚至会一丝不苟地重现过去不理想的实现模式。仅靠文档中的“努力目标”,是无法守住架构的。
そこで発想を逆にしました。アーキテクチャを「守るべきルール」ではなく、構造化されたスキーマとして定義し、人間とAIの双方がそれに従うしかない形にします。Swiftの型システムがコンパイル時に不正を弾くのと同じ発想を、アーキテクチャのレイヤーにスキーマという形で持ち込みます。それが本記事で紹介する**「スキーマでアーキテクチャを縛る」アプローチ**です。副産物として、設計からコードを自動生成するパイプラインも動いています。
于是我们反转了思路。不再将架构定义为“应该遵守的规则”,而是将其定义为结构化的schema,让人类和AI双方都只能遵循它。将Swift类型系统在编译时拦截错误的相同思路,以schema的形式引入到架构的层级中。这就是本文介绍的**“用schema约束架构”的方法**。作为副产品,从设计自动生成代码的流水线也在运行。
目次
目录
どんなスキーマを定義したのか
定义了怎样的schema
全体像はこうなっています。
整体架构如下所示。
仕様書 (Confluence) / デザイン (Figma) / 既存コード
│
▼ /architecture
┌─────────────────────┐
│ 設計 YAML │ ←── AI / Codegen 向け
│ Human Doc (Markdown) │ ←── 人間向けレビュー資料
└─────────────────────┘
│
▼(人間がレビュー・編集)
│
▼ /codegen
Swift コード一式
↑ 全工程でガイドラインとテンプレートが参照される
土台となっているのが、チームで整備した 2つのドキュメント です。
其基础是团队整理的2个文档。
architecture-guidelines.md— 各コンポーネントのスキーマ(何が正しいか)architecture-guidelines.md— 各组件的Schema(什么是正确的)architecture-templates.md— スキーマからSwiftを導出するテンプレート(どう書くか)architecture-templates.md— 从Schema导出Swift的模板(如何编写)
architecture-guidelines.md — コンポーネントをスキーマで縛る
architecture-guidelines.md — 用schema约束组件
各コンポーネント(ViewModel、Repository、Translatorなど)を、型・依存・命名・必須ルール・禁止パターンなどのフィールドで厳密に定義しています。たとえばViewModelのスキーマは次のとおりです。
各组件(ViewModel、Repository、Translator等)通过类型、依赖、命名、必须规则、禁止模式等字段进行严格定义。例如ViewModel的schema如下所示。
### ViewModel
- type: \`@MainActor final class\`
- imports: [Foundation, Combine]
- imports_forbidden: [APIModule]
- depends_on: [RepositoryProtocol, UIModelTranslator, DataModel, UIModel]
- nested_types: [ViewState, Router]
- naming: {F...