<< DDDの Entities パターンと Value Objects パターンを理解する | main | ドメイン駆動設計:Aggregates パターン <ブドウの房> >>

ドメインオブジェクトの複雑な参照関係を扱うパターン

ドメイン駆動設計では、ドメインのオブジェクトを、

・シンプルに
・小型に
・役割を単純に

することが良い設計。

オブジェクト間の関連は、最小化の原則、つまり、できるだけ単純な関連がよい設計。

このモデルを、メモリ上で生成し、短時間で消滅させるなら、話しは比較的簡単。
コンストラクタとガベッジコレクタが、やっかいな仕事の多くをやってくれる。

やっかいなのは、エンタープライズアプリケーションの「大量のデータの記録(永続化)と参照」という課題。

ドメインオブジェクトの複雑なWeb


ビジネスのデータは、単独では存在していない。
必ず、他のデータとの絡み合い、参照関係の中で意味を持つ存在。

ドメインモデリングで、関連を本質的なものだけに、いくら単純にしても、それなりに複雑なオブジェクトのネットワークになる。

ましてや、永続化した過去のデータも含めた参照関係を維持するドメインオブジェクトのネットワークは、複雑で巨大になる。
長い長い参照パスをたどる必要がある。

こういう複雑なドメインオブジェクトのネットワークで、一貫性を保ち、整合性を維持するのは、かなりたいへん。

ドメイン駆動設計は、たくさんの「小型のオブジェクト」を良い設計としている。

そういう大量の小型オブジェクトを安全にあつかうにはどうする?

三つの基本パターン


Domain-Driven Design (DDD)の第6章 "The Life Cycle of a Domain Object" では、この「巨大で複雑なドメインオブジェクトのネットワーク」を扱うために、

・Aggregates パターン ( 集約 )
・Factories パターン ( 生成 )
・Repositories パターン ( 保管 )

の三つのパターンを提唱している。

正直いって、この三つのモデリングパターンは、最初に Domain-Driven Design を読んだときには、ぴんとこなかった。

今になって考えると、原因ははっきりしている。

最初に読んだ頃


私たちのモデリング、設計・実装は、すごく大きなオブジェクトとテーブルを使っていた。

顧客オブジェクトは、フィールド数で、20や30はあたりまえだった。
顧客テーブルも、ゆうに100カラムを超えていた。

関心事がぜんぜん分離できていなかった。

こういう巨大なクラスがあたりまえだと思っていた。

そうすると、

・Aggregate
・Factory
・Repository

は、目的や使い道が理解できない。

最初から一つのクラスに集約しちゃっているし、コンストラクタがあるし、永続化は O-R マッピングで、...。

こういうモデリングパターンが必要なイメージがわかないのも当たりまえですね。

ぴんとくるようになった


ドメイン駆動設計とか、いろいろやりはじめて、「シンプルで小型のオブジェクト」が、だんだん、あたりまえになってきた。

そうすると、永続化がらみのデータアクセスのコードとか、初期化のコードが膨らんできた。

書くのがたいへん。
読むのもたいへん。
変更するのはもっとたいへん。
...

そしたら、自然に、Aggregate を設計して、 Factory や Repository を導入するようになった。
そのほうが、分かりやすいし、楽になるのは、すぐわかったから。

まあ、いまでも、Aggregate の設計がうまくできているとはいえないけど、Aggregate の設計は大切、ということは実感している。

しばらく、この 三つのパターンについて、書こうと思う。

コメント
コメントする









この記事のトラックバックURL
トラックバック
calendar
  12345
6789101112
13141516171819
20212223242526
27282930   
<< September 2020 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM