『エリック・エヴァンスのドメイン駆動設計』におけるリレーショナルデータベース

近頃、以下に挙げるようなイベントで話を聞いたり議論をしたりする中で、オブジェクト指向とリレーショナルモデルについて思いを巡らせている。

今回は、その中間報告として、『エリック・エヴァンスのドメイン駆動設計』におけるリレーショナルデータベース*1について考えたことを一度まとめておく。

永続化ストアとしてのリレーショナルデータベース

ドメイン駆動設計の原典である『エリック・エヴァンスのドメイン駆動設計』（2004年）において、リレーショナルデータベースは主要な永続化ストアの地位を占めている。

第6章「ドメインオブジェクトのライフサイクル」において、ライフサイクルの中期にあるドメインオブジェクトの格納先／再構成に関わる要素としてリポジトリが紹介される。リポジトリは、何らかの永続化ストアとのやりとりを担うドメインオブジェクトである。このやりとりの相手、つまりライフサイクル中期にあるオブジェクトの永続化先として、エヴァンスは複数の種類の永続化ストアを挙げている。しかし書籍において、永続化ストアのなかでもリレーショナルデータベースは特別に手厚い言及を受けている。

リレーショナルデータベースにオブジェクトを格納する際に考慮すべき事柄として、エヴァンスは以下のように述べている。

・データベース*2をオブジェクトの格納先として見る場合には、マッピングツールの能力に関わらず、データモデルとオブジェクトモデルをかけ離れたものにしてはならない。関係モデルと近づけておくため、オブジェクトの関係性が持つ豊かさを若干犠牲にすること。オブジェクトとのマッピングを単純化するのに役立つなら、正規化のような、関係モデルが持つ正式な標準に関して、ある程度は妥協すること。
・オブジェクトシステムの外部にあるプロセスからは、そうしたオブジェクトの格納先にアクセスしてはならない。オブジェクトが強制する不変条件に違反する可能性があるからだ。また、そうしたアクセスがあるとデータモデルが固定化されてしまい、オブジェクトをリファクタリングする際に、変更するのが難しくなる。*3

上記の引用箇所のうち、前半部分ではオブジェクトモデルとリレーショナルモデルの双方を妥協させるべきであるということが述べられている。マッピングツールが優秀であれば、永続化ストア上の形式とアプリケーション上の形式とが乖離していても技術的には困らないが、エヴァンスは複数のモデルの分離を強く警戒して、モデリングをなるべく近づけるように提唱している。

リレーショナルデータベースもまた、モデルが表現されるべき場所なのであり、オブジェクトに一方的に譲るような関係性ではない。オブジェクトの表現力を最大限活用することよりも、モデルの統一性を重視しているという事実は、ドメイン駆動設計の何たるかを考える上でも重要ではないだろうか。

「不変条件の強制」という役割の担い手

一方、後半部分では、オブジェクトが（リレーションには与えられない）特別な役割を担わされている。それは、「不変条件の強制」である。不変条件の強制は、オブジェクト（とりわけ集約）が担うものであって、リレーショナルデータベースに期待されているのは格納したオブジェクトを外部から守ることである。

データが満たすべき一定の条件の記述は、必ずしもオブジェクトの専売特許ではない。リレーショナルデータベースにおいても、CHECK制約や参照整合性制約など、さまざな制約を記述することができる。実際のRDBMS製品においてはあまりサポートされていないが、複数のテーブルをまたいだかなり複雑な制約も関係演算を利用して記述できるASSERTION（表明）というものも標準SQLには存在している。

リレーショナルデータベースの機能として、データベースの主要な機能である検索と蓄積に対応した2点、すなわち、

集合演算によるリレーションの導出（検索）
ディスクへの書き込みによる永続化（蓄積）

に加えて、3番目のものとして、

各種制約によるデータの整合性の確保

挙げるのは不当ではないと思うが、その役割はドメイン駆動設計においてはリレーショナルデータベースにはあまり期待されていないのである。

業務のルールの一部である不変条件を、オブジェクトが表現するというのは、ドメイン駆動設計にとっては重要な事柄だろう。リレーショナルデータベースに不変条件の強制を担わせるのは、「ドメイン知識の流出」につながる。業務ロジックとしてのチェックに加えてクライアントのUIでの入力チェックを行うことが否定されないのと同様に、重畳的にリレーショナルデータベース側でも不変条件を強制することは許されるだろうが、リレーショナルデータベースでしか表現されない業務ルールの存在は忌避の対象であろう。

DOMAINやASSERTIONが広くサポートされていたとしても、リレーショナルデータベースはドメイン知識を表現する場所になれたかどうかはわからない。しかし、リレーショナルデータベースにおける制約は宣言的に記述されるものであるから、大きなポテンシャルを持っているもののように思えてならない。

　コッド博士は、冗長性を制約ととらえて、それを満たしている状態を、一貫性がある状態と定義する。こうした定義は若干狭いように思う。例えば部品表では、完成品の親部品は存在してはならないという制約がある筈だが、これは冗長性とは関係が無い。冗長性と制約はイコールではないと思う。
　一方で、データに関する制約を（手続き的にではなく）宣言的に記述するというアイデアは先進的だったし、40年以上経った現在でも部分的にしか実現されていない。*4