ファクトリとリポジトリの関係
リポジトリも格納されたオブジェクトを再生成するのでファクトリとの違いに迷うことがある。
ファクトリは新しいオブジェクトを生成する。
リポジトリは古いオブジェクトを見つける。
リポジトリはクライアントからはオブジェクトがメモリ上にあるものと錯覚させなければならないです。
リポジトリとファクトリの責務は別なのですね。
また、リポジトリがファクトリに生成を移譲することもOKです。
RDBに合わせてオブジェクトを設計する
RDBとオブジェクトのマッピングについて。
オブジェクトではない構成要素のうち、最も一般的なものがRDB。これによりパラダイムの混在の問題が生じる。
両者の間にある不整合は、オブジェクトに対して重大な影響を及ぼす可能性がある。(第二部第六章りより)
一般的なシチュエーションは以下のようなケース
1. RDBの主な主な目的が、オブジェクトを格納することである。
2. RDBが、別のシステムのために設計されている。
3. RDBは該当のシステムのために設計されているが、オブジェクトを格納する以外の役割を果たしている。
1の場合はまだやりやすいですね。
両者に顕著な違いがあっても、MyBatisなんかのマッピングツールでなんとかなります。
２、３とかでは、モデルの豊かさを多少犠牲にする必要や、非正規化したりする必要もあるかもしれないです。
さらに、それがレガシーであったり、外部システムからなどから来ているという、嫌なケースも。
そんなときは、２つのドメインモデルが存在しているとみなせることが多いです。
こういったケースについては、第１４章「モデルの整合性を維持する」でこの問題を読んで行く予定。具体的には「腐敗防止層」とかが解決策になるかと思います。
また、性能問題でテーブル構造に変更が入るケースも。
しかし、ドメインモデルとデータモデルが乖離しすぎると大変になっていくので注意。
１つのテーブル行には１つのオブジェクトが基本。
外部キーは、別のエンティティに対する参照に変換されなければならないです。
ユビキタス言語はドメインモデルとデータモデルを結びつけるのに役立ちます。
データモデルのリファクタリングはデータ移行があるせいで、困難なことが多いです。このせいで、ドメインモデル側のリファクタリングが困難になることがあるかもしれない。
ドメインモデルとデータモデルは別物だけど、RDBにモデルを格納する以上、こういったマッピングするための考慮をしていかなければいけないのですね。