MODULES (別名 PACKAGES) (P109) †
要約 †
- [文脈の説明]
- モジュールは古くて確立された概念。
＊＊＊
- 問題サマリ
- モジュールによって、全体に圧倒されることなく、一部分を見ることができる。
- [問題の解決方法についての説明]
- 低結合度と高凝縮度は一般的なデザインの原則だ。
- 関連のあるモデルは同じモジュールにあったほう(高凝縮度)が理解しやすい。また、モジュール間は、低結合にしたほうがいい。モジュール間の相互作用は少ないほうが良いということ。
- モジュールをリファクタリングすることは、クラスをリファクタリングするより難しい。しかし、クラスがだんだん真の姿を現すように、モジュールも抽象化されていく。ドメインの理解をモジュールに反映させることで、モジュールの中のオブジェクトもまた進化していくのだ。
- モジュールはコミュニケーションのメカニズム。その名前によって意味が伝わるんだよ。モジュール名はユビキタス言語の一部なんだ。
Therefore:
- 解決方法サマリ
＊＊＊
アジャイル MODULES †
- モジュールは、モデルと共に進化していく必要がある。これは、モジュールのリファクタリングは、モデルと共に行われるという意味だ。でも、モジュールをリファクタリングするといろいろ大変だから、そんなことは、しばしば起きるわけじゃない。その結果(しばしば変更できないので)、モジュールは、初期のモデルにもとづいていることが多い。
- 初期のモジュール選択の誤りは、高結合度につながり、リファクタリングを難しくする。これを克服するには、経験にもとづいて、モジュールを再構成するしかない。まぁ、そんなことは少ないほうがいいけどね。
インフラストラクチャ駆動によるパッケージングの落とし穴 †
- 層アーキテクチャーはいいんだけさ、JavaEEのようなインフラに毒されて、過剰に分けられちゃってる場合がある。SessionBean?とEntityBean?を分けているのがよい例だ。これらは、概念的には一つのオブジェクトであることが多い。まぁ、永続化のコードは分離したほうがいいと思うけどね。
- 本来ひとつのオブジェクトをフレームワークの都合で、別のモジュールに分けた場合、確かに、それぞれの層の役割は理解しやすくなる。でも、そのやり方には二つの問題がある。コードがモデルを素直にあらわしていないことと、そのためにドメインモデラーがモデルを意味のある塊にする能力を失うことだ。ただ、この本はフレームワークの本じゃないから、これ以上突っ込んだことは言わないけどさ。
担当者のつぶやき †
- ドメインモデラーってフレームワークによるモジュールわけの問題だけでも、すぐに能力を失うんだね。正直そんな繊細な能力だったら実戦で役に立たないと思うよ。ある程度タフでないとね。
- DDDの顧客と開発者のコミュニケーションを通じて、モデルを成長させようという考えは、共感できるけど、じゃ実際どうやるのってところが、ナイーブ過ぎて使えないと思う。
みんなの突っ込み †
