ここでは、次のソリューションを組み合わせることで、アプリケーション品質を上げる開発方法について説明します。
- ドメイン駆動設計 (DDD)
- マイクロサービス
- アジャイル開発
- ユースケース駆動開発
- DevOps
各ソリューションの効果
ここでは、5つのソリューションの効果について次のように整理します。
- ドメイン駆動設計 (DDD) によって事業価値を上げることができる
ドメイン駆動設計 (DDD)は、事業のドメイン（ビジネスの本質的な価値を提供する領域）に基づいたソフトウェア設計手法です。
これにより、技術的な実装とビジネスの要件がより緊密に連携し、事業価値の向上が図られます。 - マイクロサービスを適用することでシステムの保守性、生産性、拡張性、可用性を上げることができる
マイクロサービスは、大規模なシステムを小さなサービス単位に分割して、それぞれ独立して開発・デプロイできるようにするアーキテクチャスタイルです。
マイクロサービスを適用することで、それが持つモジュール性とデプロイの容易性という性質によってシステム全体の保守性と生産性を上げることができます。
マイクロサービスを適用することで、それが持つ分散性と独立性という性質によってシステム全体をスケールしやすくします。
マイクロサービスを適用することで、それが持つ分散性と独立性、障害耐性という性質によってシステム全体の可用性を上げることができます。 - アジャイル開発によってシステムの適合性を上げることができる
アジャイル開発は、反復的・漸進的な開発手法で、短期間で動くソフトウェアをリリースし、フィードバックを取り入れて迅速に改善していくことが特徴です。
これにより、システムが常にユーザの期待に適合し続けるため、システムの適合性が向上します。 - ユースケース駆動開発によってシステムの適合性を上げることができる
ユースケース駆動開発は、ユーザのニーズや期待されるシナリオに基づいてシステムの機能を定義する手法です。
これにより、システムが必要な機能を適切に提供することが重視され、システムの適合性が向上します。 - DevOpsを適用することでシステムのデリバリースピードを上げることができる
DevOpsは、開発（Development）と運用（Operations）を統合して協働することで、システムのデリバリー速度を向上させることを目的とした手法です。
自動化やCI/CD（継続的インテグレーション/継続的デリバリー）の活用によって、システムの変更やリリースを迅速かつ効率的に行うことが可能です。
アプリケーション開発の全体像
次の図は、5つのソリューションを適用したアプリケーション開発の全体像を表したものです。
これを見ると、アプリケーション開発全体の流れ（方向づけフェーズから移行フェーズまで）は、ユースケース駆動開発をベースとする統一プロセスになっており、アプリケーション運用・保守の流れ（運用・保守フェーズ）はDevOpsがベースになっています。
また、推敲フェーズでアプリケーションアーキテクチャを設計、検証する際、マイクロサービスアーキテクチャと、ドメイン駆動設計のヘキサゴナルアーキテクチャを適用し、構築フェーズのアプリケーションの開発でアジャイル開発を適用していることもわかります。
方向づけフェーズ
方向づけフェーズの目標は、システムを開発する正当性について確証を得ることです。
要件定義を通して、システム開発に関する主要なリスク（不確実性）を洗い出し、それをどうコントロールするか検討します。
具体的には、アプリケーションポートフォリオのどのアプリケーションタイプを対象にするかスコープを決め、そのアプリケーションタイプのユースケースを抽出し、要件定義をします。
そして、改めて戦略マップの情報資本目標（アプリケーション）を確認し、アプリケーション開発の目的を明確にし、アプリケーション開発計画を策定します。
アプリケーションアーキテクチャ設計のプロセスでいうと、次の図のように要件定義をの部分が方向づけフェーズになります。
推敲フェーズ
推敲フェーズの目標は、システムの土台となるアーキテクチャを確立することです。
アーキテクチャに基づいて、開発要員の配分、コストの詳細見積もりを行いプロジェクト計画（詳細レベル）を完成させます。
推敲フェーズをやらずに構築フェーズに進むと、構築の途中で、共通化できる機能や基盤に関する要望が五月雨的に発生し、その都度、設計を全面的に見直すなど開発の大幅な遅延をもたらす可能性が高くなります。
具体的には、アプリケーション開発の外部設計と内部設計を行います。
外部設計では、将来ユースケースをイベントフローによって詳細化し、画面イメージ、画面遷移を設計します。
内部設計では、マイクロサービスアーキテクチャと、ドメイン駆動設計のヘキサゴナルアーキテクチャを選定し、次の手順で設計します。
- 集約の特定
アプリケーションタイプをドメインとし、ドメインの集約を特定します。
例えば、販売管理ドメインの場合、受注エンティティと受注明細エンティティのグループが集約で、受注エンティティが集約のルートになります。 - CQRSの適用
次に、ドメインをコマンド・クエリ責務分離（CQRS）パターンのコマンド処理とクエリ処理に分け、それぞれをマイクロサービスにします。
例えば、販売管理ドメインの場合、コマンド処理のマイクロサービスとして受注管理サービス、クエリ処理のマイクロサービスとして受注照会サービスを設定します。
なお、マイクロサービスを跨いだ分散システムのトランザクション管理にはSagaを適用します。 - イベントソーシングの適用
最後に、コマンド処理のマイクロサービスにイベントソーシングを適用します。
次に、DBMSも含めミドルウェアを構成する製品を選定後、アプリケーション連携モデル（論理）を設計し、ユースケースの実現性を検証します。
机上で、ユースケースの実現性が検証できたら、実際に次の手順でプロトタイプを開発してアーキテクチャを検証します。
- ユースケースの選定
まず、アーキテクチャを検証するために必要なユースケースを選定します。 - ドメインモデルの検証
ドメインモデルの妥当性をアプリケーションサービスを通して検証します。 - データ連携の検証
外部システムやDBとの連携を検証します。 - サービスの検証
マイクロサービス全体の実現性を検証します。
上記２でドメインモデルの妥当性が検証できたら、それをベースに論理データモデルを設計し、データベース（テーブル）を構築します。
アプリケーションアーキテクチャ設計のプロセスでいうと、推敲フェーズでは、将来ユースケースの設計からユースケースの実現性検証を実施後、アーキテクチャの検証を行います。
アプリケーション開発プロセスでいうと将来ユースケースの設計が外部設計で、それ以降が内部設計になります。
構築フェーズ
構築フェーズの目標は、アーキテクチャ（骨格）に基づいてシステムを実装（肉付）し、システムテストを通してシステムのベータ版をリリースすることです。
マイクロサービスアーキテクチャの場合、次の図のように、フロントエンドアプリケーションとマイクロサービスに分けて開発します。
構築フェーズでは、次の3つの開発を同期を取りなら並行して進めます。
- アプリケーション開発
スクラムなどアジャイル開発の手法を適用してアプリケーションを次の手順で開発します。- マイクロサービスの開発
以下の手順で開発します。- 実装
- 単体テスト
- ビルド
- デプロイ
- 統合テスト
- フロントエンドアプリケーションの開発
以下の手順で開発します。- 実装
- 単体テスト
- ビルド
- デプロイ
- 統合テスト
- マイクロサービスの開発
- 移行開発
データ移行プログラムを開発し、既存システムのデータを推敲フェーズで構築したデータベースに移行します。 - 運用設計
アプリケーションの保守・運用プロセスの設計と各種マニュアルの作成を行います。
移行フェーズ
移行フェーズの目標は、運用テストを通して、システムのベータ版を完成版に移行し、システムを使って業務活動を遂行できる状態にすることです。
データの移行が必要な場合、移行ためのプログラムも作成します。
なお、移行フェーズでは、システムの操作教育、システム運用・保守体制の整備などシステムを使って業務活動を遂行できるするための活動も行います。
具体的には、システムテストを実施後、次の手順で移行タスクを遂行します。
- 運用検証
アプリケーションを活用して業務が遂行できるか検証します。
あるべきビジネスプロセスは、BPMのビジネスアーキテクチャの設計、アクションフローの設計で行います。 - 受入テスト
運用検証と並行してアプリケーションの受入テストを実施します。 - ユーザー教育
運用検証と並行してアプリケーションのユーザー教育を実施します。
