実践ドメイン駆動設計第9章メモ

実践ドメイン駆動設計

実践ドメイン駆動設計 (Object Oriented Selection)

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

エリック・エヴァンスのドメイン駆動設計

• モジュール
  • Javaならパッケージ、C#なら名前空間、Rubyならmodule
• DDDの文脈ではモジュールと呼ぶことにする

9.1モジュールを使った設計

• DDDの文脈ではドメインオブジェクト内のクラスをまとめるコンテナ
  • 別のモジュールのクラス郡との結びつきを少なくする
• 適切な名前が必要
  • モデルと同じように意味や名前をきちんと検討したうえで作っていくようにする
• モジュールのべし・べからず集 => 本で確認
  • 基本的にDDDの考え方（名前が大事、モデルとコードをあわせる）にそって作る
  • ユビキタス言語も忘れずに
  • 集約やサービスごとにモジュールを分けたりしてはいけない
  • 疎結合になるように設計する
  • 循環依存が発生しないようにする
    • 親子関係は厳しさを緩める
  • モジュールもモデルと同様に柔軟性を持たせる、名前が合わないときやまとめるモデルが合わない時はどんどんリファクタリングする

9.2 モジュールの基本的な命名規約

• トップレベルの階層は組織のインターネットドメインを使うことなどがおおい
  • Javaのパッケージなんかと同じ

9.3 モデルに対応するモジュール名の命名規約

• トップレベルのあとが、境界づけられたコンテキスを表す
  • com.sassovation.collaborationとか
  • ユビキタス言語が反映されたものであるように！
    • ブランド名なんかはよく変わることがあるので、あまり良しとしないし今回の例でも使っていない
• com.sassovation.collaboration.domainでモジュールがドメインに属することを示す
  • この部分ではインターフェイスやクラスの情報は持たせない
  • domain以外だと、applicationとかinfraとかでもいい？
• domainの下にmodelだったりserviceのパッケージを作る
  • ここにインターフェイスなどを配置する
  • serviceはヘタするとドメインモデル貧血症になるので注意

9.4 アジャイルプロジェクト管理コンテキストのモジュール

• 今回の例はモジュール間の結合より、整理されていることを優先
• 組織的な強度をとるか疎結合か
  • 例だとproductとbacklogitemの親子関係
  • 疎結合性を取るために、汎用型で識別子を保持すると個々の識別子が区別できなくなる => バグの可能性！

9.5 他のレイヤにおけるモジュール

• レイヤ化アーキテクチャで、何かのドメインモデルを扱うアプリケーションの場合
  • UI、アプリケーション、ドメイン、インフラストラクチャの層に分かれる
• UIレイヤの例
  • RESTfulリソースでサポート
  • RESTfulなリソースが画面のレイアウトを決める事があってはいけない
    • com.saasovation.agilepm.resources
    • com.saasovation.agilepm.resources.view
• アプリケーションレイヤ
  • サービスごとに作られるだろう
  • UIでもアプリケーションでもサブパッケージに分けるのは役立つ場合だけにしたほうがいい

境界づけられたコンテキストの前にモジュールを検討する

• 言葉があいまいで概念的な強化を作るべきかはっきりしない場合は、（境界づけられたコンテキストを？）ひとまとめにしておくことを考える
• 境界づけられたコンテキストとモジュールは別物