読者です 読者をやめる 読者になる 読者になる

たなかこういちの開発ノート

システム開発に携わる筆者が、あれこれアウトプットするブログ

「DDD座談会」に参加してきました

DDD イベントレポート
6月5日に開催された、かとじゅん氏(Twitter:@j5ik2o)主催の「DDD座談会」に参加してきました。
 
後半戦、アルコール後は、文字通りの座談会となり、大いに盛り上がりました。
 

 
学んだことの覚え書き
 

 

 

 

 

 
LT「RDBで関心の分離」のフォロー
 
RDBで関心の分離」と題してLTいたしました。みなさまご静聴いただきありがとうございました。
 
使用した資料は下記です。
 
 
しゃべれてなかった部分も含めて、論旨を以下に改めてまとめます。
 
・「関心の分離」をテーブルで表現しよう。
・要件追加があったとき、既存テーブルにカラム追加(ALTER TABLE)せず、常にOne-to-Oneの従属テーブルを新規にCREATEしよう。
・追加される要件とは、概ね新しい独立した「関心」のはずだ。新規追加機能は、新設の従属テーブルと、その従属テーブルから"uses-a"あるいは"belongs-to"関係にある親テーブルに対するモデルを扱うので十分なはずだ。他の従属テーブルに用はないはずだ。
・例えば、
PARENT
SUBORDINATE_1
SUBORDINATE_2
という3テーブルがあったとき、
既存機能Aは、PARENT
新規追加機能Bは、SUBORDINATE_1とPARENT
新規追加機能Cは、SUBORDINATE_2とPARENT
のみに関心がある、という関係性にあると云えるはず。単一テーブルで唯一のFATモデルだと、機能A、B、Cが衝突するところである。SUBORDINATE_1、SUBORDINATE_2とOne-to-One従属テーブルに分割して、各従属テーブルに対する別々のモデルを設けることで、機能A、B、Cのモデル上の衝突を避けられる。
・結論的に、次のような三つのモデルを作成するのだ。
- 機能A向けの、PARENTを集約ルートとしたモデルとリポジトリ
- 機能B向けの、SUBORDINATE_1を集約ルートとしたモデルとリポジトリ
- 機能C向けの、SUBORDINATE_2を集約ルートとしたモデルとリポジトリ
・ところで、このようにOne-to-One従属テーブルに分割した時、各テーブルのレコード数がどうなるか鑑みると、PARENTテーブルのレコード数を100としたら、各SUBORDINATEテーブルでは、要件次第だが、いずれにしろ100より大幅に少ないケースがよくある。(※仮にカラム追加で単一テーブルとした場合は、NULLだらけのすかすかテーブルになるところである。)
・データに対して、ある要件に基づいて属性追加が為される時、その要件に該当し、追加属性に何らか値がfillされるようなEntryは、大抵は、母集団に対して一部なのである。このような様子を「One-to-"Less Than One"」と称しよう。「One-to-"Less Than One"」な状況にある時、実際にOne-to-Oneにテーブルを分割することは、データ容量効率やインデックスの効率にも寄与し得る。
※この最後の点は、細かいテーブルを複数作ることに反対意見が出たときに、“相手側土俵に立っての反論”として有用ですヨ。
 
◆以上