エリックエヴァンスのドメイン駆動設計を読んでいる(第2部 第4章)

ドメインを隔離する

うちの現場でも採用されているレイヤー化アーキテクチャについての章。 プロダクトをUI層、アプリケーション層、ドメイン層、インフラストラクチャ層の４つに分けている。

上の層は下の層にただ一方的に参照を行うことができる。

このような制約をもたせて、各層に分けることで各層は凝縮度が高く、層ごとに疎結合な設計ができるらしい。

これによって例えばUIを変えたいのにインフラ周りまで影響を及ぼしていたりとかってことがなくなる。 これを守っていないと伝統的なスパゲッティ状態になるわけですね。

そう考えるとこれはとても大切な気がする。これを守らずに死んでいった開発者たちはきっと多いんだと思う。 そう考えるとなんか味わい深いですね。

UI層

ユーザーに情報を表示してユーザーのコマンドを解釈する責務を負う。

アプリケーション層

ソフトウェアが行う仕事を定義し、ビジネスにとって意味のあるものか、あるいは他のアプリケーション層と相互作用するために必要なものを扱う。このレイヤーは決してビジネスルールや知識は含まず、薄く保つことが大切。

ビジネスの状況は保持しないが、トランザクションなどの処理の状態は持つことができる。

ドメイン層

ビジネスロジックを持つ。一番大事な核心部。

インフラストラクチャ層

上位のレイヤを支える技術的な機能を提供する。 DBにデータを永続化したり、他の層から利用される部品を入れておいたりする。

何より、ドメイン層を分離するということが大事

ここら辺についてはまた別の資料でお勉強する必要がありそう。

レイヤを関係づける

上位のレイヤ破壊のレイヤにある要素を直接使用したり操作したりできる。 これは、公開インタフェースを呼び出したり、要素の参照を保持したりするか、相互作用のための従来の手段を使用することによって行われる。

相互作用のための従来の手段を使用することってどういうことですかね？なんかイメージがわかないです。

アプリケーションがメールを送る必要がある場合、何らかのメッセージ送信インタフェースがインフラ層にあり、アプリケーション層がメッセージの送信を行う。アプリケーション層をシンプルにして、アプリケーション層が担うべき「メッセージをいつ送信するのかは知っているが、どのように送信するのかは知らない」という責務を果たさせる。

ここ今日まさに仕事中に考えてたことだw正解だったよかった。メッセージ送信のための部品はユーティリティとしてインフラ層に置いておいて、アプリケーション層が直接それを呼び出すように仕事でも設計した。メッセージングが別のサービスに切り替わる可能性も考えて、別のサービスとやりとりさせる場合に備えてアプリケーション層に実装しました。