鳥の目も虫の目も持つためのモジュール（パッケージ)

全体によって圧倒されることなく、モジュール内部の詳細を見ることができるし、その一方で、内部の詳細を無視した上で、モジュール間の関係性を見ることもできるのだ。

つまり鳥の目も虫の目も持つためのモジュール。

物事の全体を見ているだけでは細部はわからず、部分に注目するだけでは全体性を見失う。(学習パターンNo.19 鳥の目と虫の目より)

モジュールはドメインを学習するために必要不可欠なものだと思います。

モデルとしてのモジュール

ドメイン層のモジュールは、モデルにおいて意味のある一部として現れ、より大きな尺度でドメインのことを語らなければならない(第二部第五章より)

整理するためにモジュールやパッケージを活用するチームは多いとおもいますが、ドメイン駆動で設計しているチームでも、モデルとして扱っているチームは少ないかもしれません。

「ドメインのことを語らなければならない」というのはそのままの意味かと思います。

例えば、

model
|---- item
|---- member
|---- order

というフォルダ構成であれば、「"会員"が"商品"を"注文"する」と語るのであります( ･ิω･ิ)

モデルが物語だとすれば、モジュールは章に相当する。(第二部第五章より)

そして、これは鳥の目のためのモジュール

例えば、memberの中を見れば虫の目でモデルを確認できます。

モジュールでモデルをわけることにより、モデリングや設計を小さいモジュール単位で扱うことができるようになります。
人間が一度に覚えることのできる数は７個前後と言われています。
こういうのも意識してみるといいかもしれませんね。

関連のあるモデルをモジュールに集め、関連の薄いモデルを疎結合に保つために別のモジュールに移動していきます。
凝集度と結合度は、オブジェクト指向の基本のパターンですね。
それをモジュールにも適用します。

パッケージ図を書くといいですね。

モジュールはモデルの一部にも関わらず、初期に設計したあとはあまり変更されることがありません。
しかし、モデルは変化し、進化するもの。モジュールを修正するのは、ソースコードを修正するよりインパクトがありますが、モデルの進化に合わせて、リファクタリングしていくことが大事。

コンフリクトを起こしたりすることも多々あるかと思いますが、歯を食いしばってリファクタリングしましょう。

今のプロジェクトでも、何回かモジュールの変更を行いました。一人でリファクタリングしても影響が大きく、その間誰もソースをいじれなそうだったので、モジュールを変更する際には全員が集まって、その場で変更してしまっています。モブプログラミング的なプラクティスですね。