これまでの１６章

責務のレイヤ

大きく増えた、コンテキスト群を整理するために、責務のレイヤを利用します。

レイヤアーキテクチャと同じように、上のレイヤは下のレイヤを参照できるが、下のレイヤは上のレイヤを参照はできない。

確かに、レイヤ化すると整理がしやすく、見通しが良くなるかもしれない。
問題はどうレイヤを発見するか？

まずは、モデルの依存関係を調べる。
それによって、自然なレイヤが出来ているのが発見できるかもしれない。

ただ、それぞれのレイヤに意味が見いだせなければ、整理はできるが、それ以上のモデルに対する洞察やモデルに関する意思決定はできない。

なので、ただの依存関係ではなく、概念上の依存関係を調べるのが大事。

そして、レイヤが何を意味しているのかを知ること。その責務はシステムの目的と設計を語るものであること。各オブジェクト、集約、モジュールがレイヤの責務の範囲に収めること。

ドメインが頻繁に変更されたりする箇所や、その原因がそのレイヤの責務を表している可能性もあるので注視しておくと良いかもしれません。

また、レイヤ自身も切り替え、マージ、分離などで再定義されるものです。

大規模な構造の各パターン今まで採用したことがないのですが、
このパターンを読んで、自分の今のドメインであるECサイトでもいけるかもと思いました。

たとえば、実際の売買（金流・物流)を責務とする層と顧客対応や経理等の業務を責務とする層とか。
業務を責務とする層は売買を責務とする層を利用するが、逆はないのでレイヤ化できそうです。

今回はなかなか、うまくすれば使えそうなパターンですね。