どれほど優れた設計図を最初に描いても、開発が進むにつれてモジュール間の依存関係は複雑化します。気づかぬうちに「一箇所直すと関係ない場所が壊れる」というスパゲッティ・アーキテクチャに陥るのを防ぐには、継続的な「検証」が不可欠です。
今回は、Architecture Canvasを維持するための3つの鉄則と、それを自動チェックする強力なツールについて徹底解説します。
1. アーキテクチャを維持するための「3つの黄金ルール」
OutSystemsのアーキテクチャ検証には、絶対に守らなければならない3つのルールがあります。これらは単なる推奨事項ではなく、システムのライフサイクル（デプロイ）の独立性を守るための生命線です。
ルール①：上方参照禁止（No Upward References）
下位レイヤーのモジュールが、上位レイヤーのモジュールを参照してはいけないというルールです。
| なぜダメなのか？ | 下位のモジュール（例：Foundation）が上位（例：End-User）を参照すると、本来独立しているはずのモジュール同士が「クラスター（塊）」になってしまいます。その結果、Foundationをデプロイする際に関係ないEnd-Userアプリまで芋づる式に引き連れてしまい、ランタイムのフットプリントが不必要に増大します。 |
| 解消法 | 参照されている要素を、適切な下位レイヤー（CoreやFoundation）に移動させます。 |
ルール②：End-User間のサイド参照禁止（No Side References）
End-Userレイヤーのモジュール同士が直接参照し合ってはいけないというルールです。
| なぜダメなのか？ | End-Userモジュールはアプリケーションの「終着点」であり、他のモジュールにサービスを提供する場所ではないからです。サイド参照を許すと、別々のプロジェクトチームが管理しているアプリ同士のライフサイクルが密結合になり、個別のリリースができなくなります。 |
| 例外 | 画面遷移（Screen Reference）のみ、OS11では「弱い参照」として許容されます。 |
| 解消法 | 共有したいアクションやエンティティがある場合は、Coreレイヤーのモジュールへ昇格させます。 |
ルール③：Core/Foundation内の循環参照禁止（No Cycles）
同じレイヤー内であっても、モジュールAがBを参照し、BがAを（直接的または間接的に）参照する状態は避けなければなりません。
| なぜダメなのか？ | 循環参照は、「コンセプトの抽象化が不十分」であることを示しています。2つのモジュールが物理的に一つの大きな塊として扱われるため、変更の影響範囲が制御不能になります。 |
| 解消法 | 強く結合しすぎている場合はモジュールを統合（Merge）するか、上位に新しいビジネスロジック層（_BL）を作成してオーケストレーション（Composition）させます。 |
2. その他の重要推奨事項
試験によく出る「盲点」となるベストプラクティスも押さえておきましょう。
| 推奨事項 | 理由 |
|---|---|
| Coreレイヤーに画面を置かない | テスト用の画面であっても、Coreモジュールに含めてはいけません。本番環境でセキュリティホールになるリスクがあるため、テスト画面は専用のEnd-Userモジュールへ配置すべきです。 |
| 公開エンティティはRead-Only | Coreサービスで公開するエンティティは「Read Only = Yes」に設定します。データの更新は必ずカプセル化された「Public Action」経由で行わせることで、ビジネスルールの強制と監査（Auditing）が可能になります。 |
| Foundationにビジネスロジックを置かない | 基盤層は「Business Agnostic（ビジネスに依存しない）」であるべきです。特定の業務知識が必要なロジックはCore層以上に配置します。 |
3. 検証を加速させる2つのツール
手動で数千の参照をチェックするのは不可能です。OutSystemsは2つの強力なツールを提供しています。
① Discoveryツール（分析と可視化）
Forgeから無料でダウンロードできる、アーキテクチャ分析に特化したツールです。
| 特徴 | 命名規則（_CS、_isなど）に基づいてモジュールをCanvasの各層に自動分類し、実際の依存関係を視覚的な「マップ」として表示します。 |
| 用途 | 「どの要素がどのルールに違反しているか」をピンポイントで特定し、リファクタリングの優先順位を決めるのに最適です。 |
② AI Mentor Studio（技術的負債の監視）
インフラ全体の健全性を鳥瞰できる、SaaS型のガバナンスツールです。
| 4つの分析カテゴリ | Performance・Architecture・Maintainability・Securityの観点からコードをスキャンします。 |
| AI自動分類 | AIエンジンがコードの関係性を分析し、命名規則に頼らずともモジュールのレイヤーを推定します。 |
📝 試験頻出：AI Mentor Studioの4カテゴリを覚えよう
Performance / Architecture / Maintainability / Securityの4つです。「Usability」は含まれない点が試験でよく問われます。
4. 試験対策：リファクタリングの優先順位
試験で「リファクタリングの優先順位」を問われたら、「影響の大きさ」で考えてください。
| 優先度 | 対象 | 理由 |
|---|---|---|
| 🔴 最優先 | End-User層の違反 （上方・サイド参照） |
ここを直すと、不適切な巨大クラスターを劇的に小さくできます。 |
| 🟠 次点 | Core層の循環参照 | コアコンセプトの絡まりを解くことで、再利用性が向上します。 |
| 🟢 最後 | Foundation層のサイド参照 | 階層の底辺にあるため、他への波及効果が限定的です。 |
第4回のまとめ
✅ この回のポイント
- 3つの黄金ルール：上方参照禁止・サイド参照禁止・循環参照禁止は、デプロイ独立性を守る生命線です。
- 例外はひとつだけ：OS11でEnd-User間に許容されるのは画面遷移（Screen Reference）のみです。
- AI Mentor Studioの4カテゴリ：Performance・Architecture・Maintainability・Securityを確実に暗記してください。
- リファクタリング優先順位：End-User違反 → Core循環参照 → Foundation の順で対処します。
コメント