1. Architecture Canvasとは何か？
Architecture Canvasは、アプリケーションアーキテクチャを体系的かつ迅速に設計するための3層（以前は4層）のフレームワークです。その主な目的は以下の3点に集約されます。
- 正しい抽象化：再利用可能なサービスやコンポーネントを適切に抽出する。
- ライフサイクルの独立性：各モジュールが他の影響を受けずに独立して進化・デプロイできるようにする。
- 変更影響の最小化：一箇所の変更がシステム全体に波及する「スノーボール効果」を防ぐ。
📝 OS11における重要な変更点
OutSystems 11以降では、画面参照が「弱い依存関係」となったため、かつて存在したOrchestration（オーケストレーション）レイヤーは非推奨となり、現在は3つの主要なレイヤーで構成されています。
2. 3つのレイヤーの役割を深く知る
Architecture Canvasは、上から「End-User」「Core」「Foundation」の3層に分かれています。それぞれの層には配置すべき要素が厳格に定められています。
① End-Userレイヤー（ユーザーインターフェース層）
ユーザーとの直接的なインターフェース（UI）やプロセスをサポートする層です。
| 項目 | 内容 |
|---|---|
| 主な要素 | 画面（Screens）、特定のユースケースに特化したビジネスプロセス、UIステータスを保持するためのエンティティなど |
| 重要ルール | このレイヤーは他のモジュールにサービスを提供してはいけない。他のEnd-Userモジュールから参照されると、ライフサイクルの独立性が損なわれる |
② Coreレイヤー（コアビジネス層）
ビジネス概念（例：患者、注文、製品）に基づいたサービスやビジネスルールを保持する層です。
| 項目 | 内容 |
|---|---|
| 主な要素 | ビジネスエンティティ、CRUDアクションをカプセル化したアクション、ビジネス固有のUIブロック（Core Widgets） |
| ベストプラクティス | 公開するエンティティは「Read Only = Yes」に設定し、データの操作は必ずカプセル化されたアクション経由で行う。これにより、データの整合性と監査（オーディット）の強制が可能になる |
③ Foundationレイヤー（基盤層）
外部システムへの接続や、ビジネスに依存しない（Business Agnostic）非機能的な要件を扱う最下層です。
| 項目 | 内容 |
|---|---|
| 主な要素 | 外部APIをラップする統合サービス（Integration Services）、汎用ライブラリ、共通UIパターン、テーマ（Look & Feel） |
| 注意点 | このレイヤーにはビジネスロジックやビジネス固有のエンティティを配置してはいけない |
3. パターンの正規化：命名規約（サフィックス）の活用
モジュールの性質を一目で判断し、チーム間のコミュニケーションを円滑にするために、命名規約（サフィックス）の採用が強く推奨されます。これは、Discoveryツールなどの検証ツールがレイヤーを自動分類するための基準にもなります。
| レイヤー | サフィックス | 解説 |
|---|---|---|
| Foundation | _is |
Integration Service：外部システムとの接続をラップし、OutSystems内で扱いやすい形に正規化します。 |
_lib |
Library：ビジネスに依存しない汎用的なユーティリティやプラグインです。 | |
_th |
Theme：アプリケーションの共通のルック＆フィール（CSS、ロゴ、レイアウト）を定義します。 | |
_pat |
Pattern：再利用可能なUIパターン（カレンダー、アコーディオンなど）を保持します。 | |
| Core | _CS |
Core Service：ビジネスエンティティとその操作アクションをカプセル化します。 |
_BL |
Business Logic：複数のコアサービスを組み合わせて複雑なビジネスルールやオーケストレーションを実現します。 | |
_sync |
Synchronization：モバイルのローカルストレージとサーバー間のデータ同期ロジックを分離します。 | |
_Eng |
Engine：計算量が多く非常に技術的なビジネスルール（保険シミュレータなど）を分離します。 |
📝 モバイル専用モジュールの場合
サフィックスの前に M を付けます。（例：_MTH、_MCS）
4. モジュール間の依存関係を検証する3つのルール
設計がArchitecture Canvasに従っているかを判断するために、以下の3つの検証ルールを遵守しなければなりません。
🚫 ルール1：上方参照禁止（No Upward References）
下位レイヤーのモジュールが上位レイヤーを参照してはいけません。これが破られると、デプロイ時に不要なモジュールまで芋づる式に引き連れる「巨大なクラスター」が発生します。
🚫 ルール2：End-User間サイド参照禁止（No Side References）
画面遷移（弱い参照）を除き、End-Userモジュール同士で要素を直接参照してはいけません。再利用したい要素がある場合は、Coreレイヤーへ昇格させるべきです。
🚫 ルール3：循環参照禁止（No Cycles）
CoreやFoundationレイヤー内であっても、モジュールAがBを参照し、BがAを参照するような構成は避けるべきです。これは概念の抽象化が不十分であることを示しています。
第1回のまとめ
✅ この回のポイント
Architecture Canvasは単なる図ではなく、「変更に強く、メンテナンスしやすいシステム」を作るための地図です。正しいレイヤーへの配置と、命名規約による「パターンの正規化」を徹底することで、開発スピードと品質を両立させることができます。
コメント