こんにちは、”はふぃ”です。
レイヤードアーキテクチャってご存知ですか？
ドメイン駆動設計におけるアーキテクチャの一種でドメイン層が独立していることが特徴だそうです。
うん、全くわからん。笑
これだけでわからないのは当然なのですが、アーキテクチャの説明は概念の説明が最適化されすぎていて、読んでもイメージがわかないことが多いです！
サンプルとしてコードを紹介してくれてるサイトもよくあるのですが、個人的には「概念とコードの間にもう少しわかりやすいサンプルが欲しい！」と思ってしまいます。
そこで、簡単なサンプルを用いながらレイヤードアーキテクチャのイメージがわきやすいように説明してみたいと思います。
※ レイヤードアーキテクチャに関しては全くの初心者なので間違っている部分もあるかもしれません。ご了承ください。
レイヤードアーキテクチャとは
概念の説明は分かりづらいとはいえ、説明しないと流石に何もわからないので簡単に説明します。
レイヤードアーキテクチャは下記のように４つのレイヤーで構成されます。
依存方向は上から下へに限定されているので、例えばDomain層はUI層とApplication層でどんな変更が行われても影響を受けません。
それぞれの層に関しては以下です。
- UI（Presentation）層
- 表示に関する処理を扱う層
- Application層
- ユースケースごとにドメインオブジェクトのコーディネートを行う処理を扱う層
- Domain層
- ビジネスロジックや仕様などを扱う層
- Infrastructure層
- 永続的なストアやテクノロジーを扱う層
サンプルを使って説明
上の説明だけだと全くイメージがわかないと思うので、「本の販売を行うWEBサービス」をサンプルにして説明します。
WEBサイト
- ユーザーが実際に見るWEBサイトの表示部分
- 所謂、クライアントサイドと呼ばれる部分
- APIを利用して表示に必要なデータを取得する
API
- ドメインオブジェクトである「本」のデータを取得する
- 「本」のデータの更新や削除を呼び出すこともあるが、どうやって更新するのかなど処理はこちらでは定義しない
- UI層である「WEBサイト」でどのような変更が行われても影響しない（APIはただ取得や更新のメソッドを提供するだけ）
本
- ドメイン層のドメインオブジェクトを表す
- 分かりやすくするために「本」だけを書いたが、ドメイン層では「本」を作成・更新・削除などの処理も含む
- タイトルや著者など「本」の要素もここで扱う
- APIが本に対する処理（更新や削除など）をどのように呼び出すか、どれだけ呼び出すかなどは影響しない
データベース
- 「本」をどのように保管するのかといった処理を扱う
- 今回は「本」だが、これが「動画」に変わったとしても影響を受けない
レイヤードアーキテクチャのメリット・デメリット
メリット
- 影響箇所が明確
- ある層を変更した場合、影響を受けるのはその上の層のみなので対応しなければいけない箇所が分かりやすい
- つまり、変化に強い
- ドメイン層だけを見れば、データの整合性ルールがわかる
- 例えば、「本のタグは変更してはいけない」というルールがあった場合、更新はドメイン層でしか行わないのでドメイン層を見るだけでルールがわかる
デメリット
- 仕組みを作るのが大変
- どのアーキテクチャでも言えるが、どうしても導入コストがかかる
- チーム開発の場合などは共通認識を作るのも大変
- 変化が少ないプロジェクトにはオーバースペック
- 通常よりもコストをかけて仕組みを作るので（コード量なども多くなる）、変化が少ない（メリットがあまり得られない）場合には不向き