Domain-Driven Design の5章で、モデリングの基本ツールとして、関連を取り上げている。
パターンとしてカタログに一部になっていないけど、モデリングの基本事項は、まず、関連の説明から始まっています。
簡単に言えば、できるだけ関連を描かないのが基本思想。
・ほんとうに関心ごとの関連だけを描く
・双方向より単方向にする
・1:N 関連より、1:1 関連にする ( 限定子 )
...
こうすることで、関連モデリングが、ドメインの知識を豊かに表す手段になる。
モデルを実装する方法、設計についてもいろいろ興味深い議論が書かれている。
単方向の実装は、set への参照。まあ、これは自然ですね。
限定子を使ったら、 Map への参照。 Key で一意に特定するんだから、実装は、Map だということですね。
SQL で実装という選択肢も、検討している。
ここらへんの議論は、Fowler も、いろいろ取り上げている。
・アナリシスパターンの 14.1 関連の実装 ( Implementing Associations )
・PoEAA の 12章 オブジェクトリレーショナル構造パターン
クラス図では、箱と箱をつなぐ単純な線だけど、一本の線の引き方で、クラスの設計、テーブルの設計、SQLの設計と、さまざまな課題がでてくる。
基本は、ドメインの構造を、できるだけ素直に実装するのが正解(のはず)。
ただ、システムの規模が膨らんで、データ量や同時並行処理などの問題が大きくなると、性能やロックの問題も含めて、かなり厄介な設計問題になる。
でも、Evans のドメイン駆動設計での説明を読んでいると、ドメイン側の要求でもないのに、不必要に、実装を複雑にしたり、重くしてきたことに気づかされた。
関連を丁寧に分析・モデリングする。
重要な関心ごとの関連だけに集中する。
関連の実装パターン(基本パターン)を忠実に採用する。
ことで、問題はだいぶ改善しそうです。
パターンとしてカタログに一部になっていないけど、モデリングの基本事項は、まず、関連の説明から始まっています。
簡単に言えば、できるだけ関連を描かないのが基本思想。
・ほんとうに関心ごとの関連だけを描く
・双方向より単方向にする
・1:N 関連より、1:1 関連にする ( 限定子 )
...
こうすることで、関連モデリングが、ドメインの知識を豊かに表す手段になる。
モデルを実装する方法、設計についてもいろいろ興味深い議論が書かれている。
単方向の実装は、set への参照。まあ、これは自然ですね。
限定子を使ったら、 Map への参照。 Key で一意に特定するんだから、実装は、Map だということですね。
SQL で実装という選択肢も、検討している。
ここらへんの議論は、Fowler も、いろいろ取り上げている。
・アナリシスパターンの 14.1 関連の実装 ( Implementing Associations )
・PoEAA の 12章 オブジェクトリレーショナル構造パターン
クラス図では、箱と箱をつなぐ単純な線だけど、一本の線の引き方で、クラスの設計、テーブルの設計、SQLの設計と、さまざまな課題がでてくる。
基本は、ドメインの構造を、できるだけ素直に実装するのが正解(のはず)。
ただ、システムの規模が膨らんで、データ量や同時並行処理などの問題が大きくなると、性能やロックの問題も含めて、かなり厄介な設計問題になる。
でも、Evans のドメイン駆動設計での説明を読んでいると、ドメイン側の要求でもないのに、不必要に、実装を複雑にしたり、重くしてきたことに気づかされた。
関連を丁寧に分析・モデリングする。
重要な関心ごとの関連だけに集中する。
関連の実装パターン(基本パターン)を忠実に採用する。
ことで、問題はだいぶ改善しそうです。