目次
アプリケーションアーキテクチャとは
- アーキテクチャは元々建築業界で使われていた言葉で、日本語にすると「建築様式」などと訳される。
- ソフトウェア開発では「構造」や「構成」という意味で使われるものの、明確な定義は存在せず、文脈によって解釈される。
- この記事では「アプリケーションアーキテクチャ」は「開発するアプリケーションの構造」として扱う
アプリケーションアーキテクチャ設計の目的
アプリケーションアーキテクチャを設計する目的としては、大きく以下の 3 つが挙げられる。
- アプリケーション全体の整合性の確保
- 設計品質の向上
- 拡張性・保守性の向上
アプリケーションアーキテクチャと開発工程
- ウォーターフォール開発の場合は、一般的には以下のような流れで開発が進む
- 要件定義
- 基本設計
- 詳細設計
- プログミング
- テスト
- アプリケーションアーキテクチャ設計は基本設計フェーズ内の比較的早い段階で完了させる
3 層アーキテクチャ
アプリケーションの内部をプレゼンテーション層(またはユーザーインタフェース層)、アプリケーション層(またはビジネスロジック層)、データアクセス層の 3 層に分けてアプリケーションを構成する基本的なアーキテクチャを 3 層アーキテクチャと呼ぶ。
プレゼンテーション層
ユーザーインタフェースやクライアントサイド等アプリケーションの利用者とやり取りするのが役割。
上図ではプレゼンテーション層において、外部からのリクエストを受け取り、適切なサービスとやり取りをして、レスポンスを返す
プレゼンテーション層では以下のような処理が実装される
- URL やアクションタイプ（GET、POST、PUT、DELETE など）の解析処理
- リクエストに基づいて適切なサービスメソッドやアクションを呼び出す。
- 認証や権限付与のチェック
- リクエストの前処理や後処理
アプリケーション層
ビジネスロジックを処理する中間層で、システムのビジネスルールに従ったデータの処理を行う 上図では、dataaccess 層にある Gateway を呼び出して Record を取得し Output を返す
アプリケーション層では以下のような処理が実装される
- ビジネスロジックの実行
- 複数のデータソースやコンポーネントからのでーたの統合
- 処理結果をプレゼンテーション層に返すためのデータの準備
データアクセス層
データベースやファイルシステムなどのデータソースへのアクセスを提供する層
上図では、テーブルと 1 対 1 対応するクラスを作成し、対象のテーブルとのやりとりを記述する、Table Data Gateway パターンを採用しており、 テーブルと対応するデータの入れ物クラスである Record とデータストア(データベースやファイルシステム)へのアクセスを提供し、データの永続化・取得等の機能を担う
データアクセス層では以下のような処理が実装される
- データベース接続
- CRUD（Create, Read, Update, Delete）操作の実行
- SQL クエリの構築と実行
レイヤードアーキテクチャ
プレゼンテーション層 → アプリケーション層 → ドメイン層 → インフラストラクチャ層※と一方向に依存が流れている
このような構成をレイヤードアーキテクチャという
※ レイヤードアーキテクチャではデータアクセスの代わりにインフラストラクチャという単語を使うことが多い。
上記の 3 層アーキテクチャの構成だとサービスクラスが肥大化してしまうため、ビジネスロジック層(アプリケーション層)をアプリケーション層とドメイン層に分離させ、ドメイン層に Model というクラスを配置した。
ビジネスロジックとは
「システムのコア」や「システムの目的の処理をするところ」
- ビジネスロジック層の処理は二種類に分けると整理しやすい
- ユースケース(アプリケーションビジネスルール)
- 処理の流れを実現すること
- ドメインロジック(エンタープライズビジネスルール)
- システム都合ではないコアなルール
- ユースケース(アプリケーションビジネスルール)
ビジネスロジックの実装方式
トランザクションスクリプトパターン
- 概要
- データの入れ物と処理を分離する
- 手続き型プログラミング
- Service がドメインロジックとユースケースを担当
- メリット
- 学習コストが低い
- デメリット
- 同じロジックが Service クラス間に分散しやすく、変更に弱い
- Service クラスが肥大化しやすい
ドメインモデルパターン
- 概要
- データの入れ物に処理も持たせる
- オブジェクト指向プログラミング
- Model はドメインロジックを担当
- Service はユースケースを担当
- メリット
- 同じロジックが分散しにくく、変更に強くなりやすい
- Service クラスが肥大化しにくい
- デメリット
- 学習コストが高い
レポジトリパターン
- ドメインモデルの形式でデータを読み書きするクラスを作成するもの
- Service は Repository を使うようにして、Gateway を使わないようにすればデータベースのレコードを意識せずドメインモデルの操作に集中できる
- ※ 層の間の矢印が左から右に流れるように Repository を domain 層に置いている
プレゼンテーション層
- 3 層アーキテクチャ時と同じ
アプリケーション層
ユーザーのアクションに基づいて特定のビジネスロジックを実行するサービスクラスを含む。
- アプリケーション層では以下のような処理が実装される
- ユースケースの実行(ビジネスプロセスの流れの管理)
ドメイン層
ドメイン層はシステムのビジネスルールをカプセル化する
- ドメイン層では以下のような処理が実装される
- Model: ビジネスエンティティを表し、エンティティ固有のビジネスルール
- Repository: モデルの永続化を担当
インフラストラクチャ層
インフラストラクチャ層はアプリケーションが依存する技術的な詳細をカプセル化し、データ永続化や外部サービスへのアクセスを提供します。
ヘキサゴナル・オニオン・クリーンアーキテクチャ
- 上のレイヤードアーキテクチャでは、ドメイン層というビジネスロジックを扱う、最もコアな部分が技術的な詳細である、インフラストラクチャ層に依存している。
- ドメイン層はシステムのコアであり、複雑になりがち。複雑なものが他の何かに依存していると、さらに複雑になりやすい。
→ 依存性逆転の法則を使い、インフラストラクチャ層がドメイン層に依存するようにする
- ドメイン層はシステムのコアであり、複雑になりがち。複雑なものが他の何かに依存していると、さらに複雑になりやすい。
ドメイン層を中心に据えて、アプリケーション層がそれを取り巻き、プレゼンテーション層やインフラストラクチャ層がさらにそれを取り巻き、層をまたぐ矢印が全て内側を向いている。
このような構成はヘキサゴナルアーキテクチャやオニオンアーキテクチャやクリーンアーキテクチャと呼ばれることがある。
※ Service を UseCase に変更