これまでの回では、Architecture Canvasに基づいた「モジュール」単位の設計を学んできました。しかし、OutSystemsにおいて環境間（開発・検証・本番）を移動する最小のデプロイ単位は「アプリケーション」です。
モジュール設計が完璧でも、アプリケーションの切り分けを誤ると、「一つの機能を直しただけなのに、関係ない多数のアプリも一緒にデプロイしなければならない」という密結合の罠に陥ります。第6回では、この渋滞を防ぐための「4つのルール」と、UI戦略の核心を解説します。
1. 適切なアプリケーション構成のための「4つのルール」
OutSystemsは、アプリケーションを適切に分割・構成するために以下の4つの検証ルールを定めています。
ルール#1：モジュールのレイヤー化（Layer your modules）
基本中の基本です。アプリケーション内のモジュールがArchitecture Canvasの原則（上方参照禁止・サイド参照禁止・循環参照回避）に従っていることが大前提です。モジュールレベルで違反がある場合、健全なアプリ構成を築くことは不可能です。
ルール#2：アプリのレイヤー化（Layer your applications）
アプリケーション自体もCanvasのレイヤーに分類されます。そのアプリがどのレイヤーに属するかは、「中に含まれる最上位モジュールのレイヤー」によって決まります。
| アプリの種別 | 含まれる最上位モジュール |
|---|---|
| End-Userアプリ | End-Userモジュールが含まれるアプリ |
| Coreアプリ | 最上位がCoreモジュール（Foundationも含み得る） |
| Foundationアプリ | Foundationモジュールのみで構成されるアプリ |
🚫 重要：アプリ間参照もCanvasの原則に従う
CoreアプリがEnd-Userアプリを参照することは「上方参照禁止」違反となり、デプロイ時に不要な依存関係を引き込みます。モジュールだけでなく、アプリ間の参照方向も必ず確認してください。
ルール#3：所有者の混合禁止（Don’t mix different owners）
IT側の責任者（Owner）が異なるチームのモジュールを、1つのアプリに混ぜてはいけません。複数のチームが同じアプリを編集すると、デプロイ時の責任の所在が曖昧になり、管理が極めて複雑になります。責任範囲が分かれるなら、アプリも分けるべきです。
ルール#4：スポンサーの混合禁止（Don’t mix different sponsors）
ビジネスサイドの予算やリリースのペース（Pace）が異なる事業部門（LOB）を同じアプリに混ぜてはいけません。
📝 具体例
更新が非常に速い「マーケティング部」と、安定性を重視する「人事部」が同じアプリを共有すると、遅い方の承認を待たないとリリースできないというボトルネックが発生します。
2. スタイルガイド・アーキテクチャの4つのシナリオ
企業全体のルック＆フィール（CSS、ロゴ、共通レイアウト）を効率的に管理するための構成方法です。
| シナリオ | 特徴・構成 | メリット / デメリット |
|---|---|---|
| Built-in（組み込み） | OutSystems UIをそのまま利用 | 最小コスト。独自のブランド表現は限定的。 |
| Specialized（特化） | 既存テーマを拡張（Extend）して作成 | メリット：ベース側の更新を自動で享受できる。 デメリット：CSSインポート増による微細な性能影響。 |
| Clone（クローン） | 既存テーマを複製して独立させる | メリット：参照が減り、実行時パフォーマンスが最大。 デメリット：ベース側の将来の変更が反映されない。 |
| Bare minimum（最小限） | 最小限の構造のみをクローン | 既存のどのテーマにも適合しない「完全独自」の最終手段。 |
3. UIロジック（メニューとログイン）の共有パターン
複数のアプリでスタイルを共有する際、「メニュー」と「ログインフロー」をどこに定義するかでUXが決まります。
| シナリオ | 構成 | 用途 |
|---|---|---|
| Internet App （ログインのみ共有） |
メニューは各アプリのテンプレートに保持。ログインフローは共有テーマ（_th）に定義。 |
各アプリが独自のメニューを持ち、ログイン画面のみ共有したい場合。 |
| Portal （メニューとログインを共有） |
メニューとログインの両方を共有テーマ（_th）に定義。 |
すべてのアプリが単一の入り口を共有する「ポータル」形式。 |
4. 試験対策：覚え方のセット
試験問題で迷った時は、この「判断基準」をセットで思い出してください。
| 問われ方 | 判断基準 |
|---|---|
| アプリの「層」は何？ | アプリ内の一番「上位（偉い）」モジュールの層を見る。 |
| なぜアプリを分ける？ | ITチーム（責任）が違う、またはビジネス部門（ペース）が違うから。 |
| パフォーマンス重視なら？ | 「インダイレクション（間接参照）」を最小化できるCloneを選ぶ。 |
| 再利用UI（Block）のCSSは？ | BlockはBaseテーマ（OutSystems UIなど）に基づかせるのが安全。消費側のCSSを継承するため。 |
第6回のまとめ
✅ この回のポイント
- デプロイ単位はアプリケーション：モジュール設計だけでなく、アプリの切り分けがデプロイ速度を左右します。
- アプリのレイヤーは最上位モジュールで決まる：End-User・Core・Foundationの分類はアプリレベルでも適用されます。
- アプリを分ける理由は2つ：ITチーム（責任）の違い、またはビジネス部門（ペース）の違いです。
- スタイルガイドはトレードオフ：更新継承ならSpecialized、パフォーマンスならCloneを選びます。
コメント