アプリケーションアーキテクチャ（AA）は、ビジネス要件（戦略の実現、各種報告の信頼性確保、各種法規の遵守）に対するアプリケーション戦略を実現するアプリケーションの仕組をモデル（青写真）として表したものです。
ここでは、
ここでは、アプリケーションアーキテクチャ（概念レベル）の設計にとアプリケーションアーキテクチャ（論理レベル）の設計従って、次の手順で、具体的にアプリケーションアーキテクチャを設計する方法について説明します。
アプリケーションアーキテクチャ（概念レベル）の設計
ここでは、アプリケーションアーキテクチャ（概念レベル）の設計について次の順で説明します。
アプリケーションポートフォリオの設計
アプリケーションポートフォリオの設計については、記事「アプリケーションポートフォリオの設計」を参照ください。
ユースケースの洗出
アクションフローからフロントエンドアプリケーションのユースケースを洗い出しユースケースモデル（概要）を作成します。
フロントエンドアプリケーションは、アクションフローのレーンのジョブごとに定義します。
例えば、「製品の受注」アクティビティのアクションフローが次のような場合を考えます。
ここでは「受注の登録」と「出荷の予約」というアクションをシステムを使って行うものとします。
そこで、販売管理者のフロントエンドアプリケーションを販売管理フロントエンドシステムとすると、次のようなユースケースモデルを定義することができます。
アプリケーション連携モデル（概念レベル）の設計
次に、フロントエンドアプリケーションとアプリケーションタイプのアプリケーション連携モデルを設計します。
アプリケーション連携モデル（概念レベル）の設計は、業務概念データフローを参考にして設計します。
「製品の受注」アクティビティの業務概念データフローは次のようになります。
これを参考にして、上記販売管理フロントエンドシステムのアプリケーション連携モデル（概念レベル）を考えると次のようになります。
- 「受注の登録」ユースケースの場合
- 「出荷の予約」ユースケースの場合
以上のアプリケーション連携モデルの設計結果を鑑みて、先のユースケースモデルを次のように変更します。
アプリケーションアーキテクチャ（論理レベル）の設計
ここでは、アプリケーションアーキテクチャ（論理レベル）の設計について次の順で説明します。
- 現行アプリケーションの分析
- アプリケーション構成戦略の策定
- 現行ユースケースの洗出
- 現行ユースケースの分析
- 現行ユースケースの詳細化
- 将来ユースケースの設計
- アーキテクチャパターン選定基準の定義
- アプリケーション製品選定基準の定義
- アーキテクチャパターンの選定
- アプリケーション製品の選定
- アプリケーション連携モデル（論理レベル）の設計
- ユースケースの実現性検証
現行アプリケーションの分析
現行のトランザクション処理アプリケーション、分析アプリケーション、変革アプリケーションを洗い出します。
次の表は、アプリケーションタイプに対応する現行アプリケーションを一覧化したものです。
アプリケーション構成戦略の策定
業務の特殊性と規模という観点で、どのアプリケーションタイプをスクラッチで開発し、どの部分に業務パッケージを適用するか明確にします。
次の図は、業務の特殊性と規模という観点で、アプリケーションのタイプを位置づけたアプリケーションマップです。
アプリケーションマップに、アプリケーションタイプをマッピングすることで、どのアプリケーションタイプをスクラッチで開発し、どのアプリケーションタイプに業務パッケージを適用するか明確にすることができます。
業務活動の規模が大きくて特殊なアプリケーションは、ビジネスのノウハウが機能として蓄積されていく部分なので変更可能性が高く、自分たちが自由に変更しずらい汎用的な業務パッケージが足かせになる可能性があります。
業務活動の規模が大きくて特殊なアプリケーションにマイクロサービスを適用する例
現行ユースケースの洗出
現行システムからアプリケーションのユースケースを洗い出しユースケースモデル（概要）を作成します。
例えば、現行のSCMシステムを利用して「受注の登録」と「出荷の予約」ができる場合、次のようなユースケースモデルになります。
現行ユースケースの分析
ユースケースをさらにケース分けしユースケースモデル（詳細）を作成します。
次の図は、上記SCMシステムのユースケースモデルを分析した例です。
「受注の登録」と「出荷の予約」のユースケースに対して、受注の登録変更するケースと出荷の予約変更するケースが派生していることがわかります。
また、受注の登録内容を変更する場合は、まず、受注の内容を確認する必要があること、受注明細の登録内容を変更、削除する場合は、まず、受注明細の内容を確認する必要があることがわかります。
それから、出荷の登録内容を変更する場合は、まず、出荷の内容を確認する必要があること、出荷明細の登録内容を変更、削除する場合は、まず、出荷明細の内容を確認する必要があることがわかります。
現行ユースケースの詳細化
アクターとシステムの相互作用をイベントフローや画面遷移図、画面定義、画面イメージとして記述します。
画面定義には、画面項目が入力か選択か、選択の場合の内容は何か、入力の場合、必須か任意かなど画面を構成する項目の仕様を定義します。
次の図は、上記SCMシステムの「受注の登録」ユースケースのイベントフローの例です。
また、次の図は、上記SCMシステムの「出荷の予約」ユースケースのイベントフローの例です。
イベントフローに記述された画面のイメージと画面遷移も合わせて記述します。
将来ユースケースの設計
機能要件やデータ要件を満たすようにあるべきイベントフローや画面を見直します。
既存システムのイベントフローや画面で機能要件やデータ要件が満たされていない場合があれば、その部分を追加、修正します。
アーキテクチャパターン選定基準の定義
アプリケーション製品選定基準の定義
アーキテクチャパターンの選定
、MVCやヘキサゴナルアーキテクチャなど各アプリケーションのアーキテクチャパターンを選定します。
アプリケーション製品の選定
業務パッケージやフロントエンドアプリケーション、BFF、マイクロサービスの製品を選定します。
ソフトウェア製品を選定するとき、ソフトウェアコンポーネントのSBOM（ソフトウェアBOM）の情報を生成します。
アプリケーション連携モデル（論理レベル）の設計
選定された業務パッケージやフロントエンドアプリケーション、BFF、マイクロサービスの製品でデータ連携モデルを更新します。
次の図は、マイクロサービスアーキテクチャを採用して、上記SCMシステムの「受注の登録」ユースケースを実現するアプリケーション連携モデル（論理レベル）を設計した例です。
また、次の図は、マイクロサービスアーキテクチャを採用して、上記SCMシステムの「出荷の予約」ユースケースを実現するアプリケーション連携モデル（論理レベル）を設計した例です。
この図でUIの部分がフロントエンドアプリケーションになります。
また、BFFとはBackends For Frontendsの略で、ソフトウェアアーキテクチャ設計パターンの1つで、フロントエンドとバックエンドの中間に位置し、双方の複雑な処理を緩和させる役割を担うサーバー機能のことです。
BFFは、UIの種類ごとに作成します。
次の図は、「出荷の予約」ユースケースをスマートデバイスで実現するアプリケーション連携モデル（論理レベル）の例です。
それから、このモデルでは、各マイクロサービスにヘキサゴナルアーキテクチャを適用しています。
ユースケースの実現性検証
最後に、アプリケーションアーキテクチャ（論理レベル）で、データ要件も含めてユースケースが実現できるかシーケンス図を描いて検証します。
次の図は、上記SCMシステムの「受注の登録」ユースケースのイベントフローをアプリケーション連携モデル（論理レベル）で実現できるか、シーケンス図を描いて検証した例です。
各マイクロサービスに対するシーケンスの部分にコンシューマ駆動契約（Consumer-Driven Contracts、以下、CDC）を適用してAPI仕様を定義します。
それから、マイクロサービス間でトランザクションを実現する場合、エラーが発生したとき補償トランザクションを発行して結果整合性を担保する必要があります。
この例の場合、在庫の引当はできたが受注の登録ができなかった場合、販売管理サービスは在庫管理サービスに「在庫引当の取消」という補償処理を実行しています。
それから、次の図は、上記SCMシステムの「出荷の予約」ユースケースのイベントフローをアプリケーション連携モデル（論理レベル）で実現できるか、シーケンス図を描いて検証した例です。
出荷を登録するとき、データ品質要件として定義された、
- 出荷インスタンスは関連する出荷明細インスタンスがないと生成されない。
- 出荷明細インスタンスは関連する出荷インスタンスがないと生成されない。
というデータの一貫性制約を保証する必要があることがわかります。
次の図は、上記SCMシステムの「出荷内容の確認」ユースケースのイベントフローとシーケンス図の例です。
また、次の図は、上記SCMシステムの「出荷内容の変更」ユースケースのイベントフローとシーケンス図の例です。
メタデータとして定義された
- 「製品の出荷登録」アクションのタイミング（製品が出荷されたタイミング）で、出荷の出荷日が設定され、出荷ステータスが完了にならなければならない。
- 出荷ステータスが完了になると、出荷内容の変更や出荷明細の追加ができないようにならなければならない。
というビジネス上のデータ要件を実現するために、出荷のステータスが完了している場合、出荷内容の変更がきないように制御していることがわかります。
このように、ユースケースの実現性を考えるときは、メタデータで定義されたデータ要件が満たされるように制御を考えます。
このように、業務パッケージ含め既存システムをマイクロサービス化したい場合、業務パッケージのユースケース（イベントフロー）をマイクロサービスアーキテクチャで実現できるか検証します。
モノリシックな既存システム（モノリス）を、マイクロサービス化する場合、データベースを分割しながら置き換えていく方法や、既存の機能を段階的に置き換えていくストラングラーパターンなどの方法があります。
しかし、既存の機能がかならずしもフロントエンドとサーバー機能に分かれているわけでもなく、適切なAPIを備えているわけてもないので、業務パッケージ含め既存システムをマイクロサービス化したい場合は、このように、既存のユースケースを分析し、それをマイクロサービスアーキテクチャで実現できるか検証することで、一度に置き換えることをお勧めします。
