優れたアーキテクチャは、単に技術的な美しさだけではなく、「ビジネスの目標」と完全に一致している必要があります。OutSystemsでは、ビジネスニーズを正しく理解し、それを保守性の高いモジュール構造へと変換するために、「Disclose（把握）」「Organize（整理）」「Assemble（組み立て）」という3つのステップからなる設計プロセスを提唱しています。
第2回では、この反復的なプロセスを具体的にどう進めるべきか、設計の核心に迫ります。
ステップ1：Disclose（把握・開示）
最初のステップは、ビジネス概念、統合の必要性、そして非機能要件を明らかにすることです。
- ユーザー要件の特定：ユーザーストーリーを分析し、「誰がアプリケーションを利用するのか」「どのような役割があるのか」「各ユーザーはどのようなアクションを実行するのか」を明確にします。
- 情報アーキテクチャの把握：既存のドキュメントの分析や、ステークホルダーとの対話を通じて、ビジネスユーザーが認識している情報の構造を確認します。
- 統合ニーズの洗い出し：外部システム（CRM, ERP, SaaSなど）からどのような情報を取得する必要があるか、通信プロトコル（REST, SOAPなど）やデータ構造を特定します。
- UXとチャネルの期待値：Webアプリなのかモバイル専用なのか、アクセシビリティ要件はあるか、といったユーザー体験に関する要件を整理します。
📝 ポイント
最初の段階で主要なコンセプトを見落とすと、後で複雑なリファクタリングが必要になり、コストが増大します。
ステップ2：Organize（整理）
ステップ1で洗い出した「コンセプト」を、Architecture Canvasの適切なレイヤーにマッピングします。この段階では、まだ「モジュール」ではなく、あくまで概念としての整理であることに注意してください。
| レイヤー | 配置する概念 |
|---|---|
| End-Userレイヤー | ユーザーインターフェースに関連する概念、画面、および特定のユースケースに特化したプロセス |
| Coreレイヤー | ビジネス上の主要な概念（例：患者、診察、契約）や、それに関連するビジネスルール |
| Foundationレイヤー | 外部システムとの統合ニーズ（API連携）や、監査・認証といったビジネスに依存しない非機能的な要件 |
📝 イテレーションについて
このステップを行う中で、新たな疑問やコンセプトが見つかることも多く、Discloseステップへ戻って詳細を確認するイテレーションが発生します。
ステップ3：Assemble（組み立て）
整理された概念を、実際に開発・デプロイ可能な「モジュール」へと組み立てていきます。ここでは、以下の4つの原則が意思決定のガイドとなります。
| # | 原則 | 内容 |
|---|---|---|
| 1 | 関連する概念の統合 | 概念的に密接に関連しているものは、同じモジュールにまとめる。例えば、「病院」と「病棟（Units）」は切り離して管理するメリットが少ないため、一つのモジュールに統合します。 |
| 2 | ライフサイクルによる分割 | たとえ関連があっても、更新頻度や変更のタイミングが異なる概念は、別のモジュールに分割すべきです。これにより、一方の変更が他方のデプロイに影響を与えないようにします。 |
| 3 | サービスと統合ロジックの分離 | 再利用可能なビジネスロジックはCoreレイヤーへ、技術的な接続ロジックはFoundationレイヤーへ隔離します。これにより、外部システムの仕様変更からコアビジネスロジックを守ることができます。 |
| 4 | 既知のパターンの適用 | ECS（外部コアサービス）パターンなど、OutSystemsで実績のある設計パターンを当てはめて、堅牢な構造を構築します。 |
まとめ：設計は「一度きりのイベント」ではない
✅ この回のポイント
アーキテクチャの設計は、プロジェクトの最初に一度だけ行って終わりではありません。開発が進み、新たな要件や技術的な詳細が判明するたびに、これら3つのステップを繰り返す「継続的なプロセス」です。このプロセスを繰り返すことで、各モジュールが独立したライフサイクルを持ち、変更による影響が最小限に抑えられた、真に「持続可能な」アプリケーションが完成します。
コメント