後半戦、アルコール後は、文字通りの座談会となり、大いに盛り上がりました。
#dddzk 盛り上がってきたww pic.twitter.com/Ytgj21us5G
— なおぴ！ (@naopi) 2016年6月5日
＃学んだことの覚え書き
そういえば、在庫管理でロックなんか必要ねぇ！という話ですが、システムじゃなくて業務フローに目を向けましょうよ、ということでした。引当も在庫に対してするんじゃなくて入庫予定に対して消し込む、とかも。在庫情報はマテリアライズドビューで十分なんです！に納得です。 #dddzk
— Okuda (@yoskhdia) 2016年6月5日
大規模はそもそも練習ができないという問題と、すべての領域に目が行き届かない問題はありそう。小規模から始めて、小規模プロジェクト間の連携を覚えて、なステップを踏んでからなのかなという感じはする #dddzk
— もう現場しか見えねえ (@uzzu) 2016年6月5日
DDD座談会後の懇親会で会話したが、どんな方法論でもどんな設計論でも、結局最後はチームへの浸透の問題になるのだ。
— たなかこういち (@Tanaka9230) 2016年6月5日
＃LT「RDBで関心の分離」のフォロー
「RDBで関心の分離」と題してLTいたしました。みなさまご静聴いただきありがとうございました。
使用した資料は下記です。
しゃべれてなかった部分も含めて、論旨を以下に改めてまとめます。
・「関心の分離」をテーブルで表現しよう。
・要件追加があったとき、既存テーブルにカラム追加（ALTER TABLE）せず、常にOne-to-Oneの従属テーブルを新規にCREATEしよう。
・追加される要件とは、概ね新しい独立した「関心」のはずだ。新規追加機能は、新設の従属テーブルと、その従属テーブルから"uses-a"あるいは"belongs-to"関係にある親テーブルに対するモデルを扱うので十分なはずだ。他の従属テーブルに用はないはずだ。
・例えば、
PARENT
SUBORDINATE_1
SUBORDINATE_2
という３テーブルがあったとき、
既存機能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にテーブルを分割することは、データ容量効率やインデックスの効率にも寄与し得る。
※この最後の点は、細かいテーブルを複数作ることに反対意見が出たときに、“相手側土俵に立っての反論”として有用ですヨ。
◆以上
