【実践ドメイン駆動設計】第4章 アーキテクヤ

4.2レイヤ

レイヤー化アーキテクチャパターンの本質的な原則はどのレイヤも、同じレイヤかその下位のレイヤとしか結合しない。

厳密なレイヤー化アーキテクチャ

直下のレイヤとの結合しか認めない 方式。

緩やかなレイヤー化アーキテクチャ

直接つながってなくても、下位のあるどのレイヤととの結合も許可する。
ユーザーインターフェイスとアプリケーションサービスはどちらもどちらもインフラストラクチャを使う必要があることが多いため。

オブザーバー、メディエイターパターン

下位のレイヤが、実際には上位レイヤーと緩く結合している。
下位のレイヤが上位のレイヤを直接参照することは決してない。
このパターンを利用する場合、下位レイヤで定義したインターフェイスを上位レイヤで実装する。そしてそのクラスのオブジェクトを下位レイヤの引数として渡すことになる。下位レイヤがそのオブジェクトを使う際は、そのオブジェクトがアーキテクチャ的にどこに位置するものかを知る必要がない。

アプリケーションサービス

アプリケーションレイヤに位置付けられる。ドメインサービスと異なり、ドメインサービスとは異なり、ドメインロジックを持たないサービス。永続化のトランザクションや、セキュリティを管理するために使うこともある。また、保管システムに通知メールを送ったり、ユーザー向けのメールのメッセージを組み立てたりする。
ドメインモデルの直接の利用者ではあるが、自分自身ではビジネスロジックは持たない。非常に軽量で、集約などのドメインオブジェクトに対する操作を調整したりする。したがってアプリケーションサービスにありがちな機能は、ユーザーインターフェイスからのパラメーターを受け取って、リポジトリを用いて集約のインスタンスを取得し、そのインスタンスに対して何らかのコマンドを実行する。

アプリケーションサービスが上記よりも複雑化するようならドメインロジックがアプリケーションサービスに漏洩している兆候。その結果モデルは貧血症を起こすことになる。 モデルのクライアントであるアプリケーションサービスはできるだけ薄いものに留めておくのが良い。
新たな集約を作る必要が出てきたら、ファクトリか、あるいは集約のコンストラクタを使ってそのインスタンスを作成し対応するリポジトリを永続化させる。

インフラストラクチャレイヤ

インフラストラクチャレイヤを最下層に置くと不都合が発生する。
例えばドメインレイヤが必要とする技術的なところを実装するのが難しくなる。レイヤ化アーキテクチャに違反せざるを得ない。コードのテストもしずらい。
→依存性逆転の原則で解決する
インフラストラクチャを最上位に位置付け、その下位に位置するすべてのレイヤでインターフェイスを実装できるようにする。
before

after

上記のアーキテクチャに基づいてインフラストラクチャレイヤでリポジトリを実装すると、そのインターフェイスはドメインレイヤで定義される。
DIPを利用すると、ドメインとインフラストラクチャの両方がドメインモデルで定義した抽象に依存することになる。