DBはそのままで、 ドメインモデルを分けた話

Transcript

1. DBはそのままで、 ドメインモデルを分けた話 DDDとモジュール分割、実際どうだった？ 2026.07.30 ／ MORIWAKI Kazuya（株式会社スペースマーケット） 1
2. 今日話すこと • Repositoryを分ける基準は、テーブルの形ではない ◦ • ドメインの意味・不変条件・更新責務の境界で決まる DBは1㍉も変えていません ◦ 100カラム超の既存テーブルはそのまま残して、モデルだけを分けた話 2
3. スペースマーケットとは スペースを借りたい「ゲスト」とスペースを貸したい「ホスト」をマッチングするサービス
4. 前提：100カラムのテーブルという現実 10年の歴史の積み重ね！ • hosts テーブル（ホストにまつわる情報）は 100カラム超 • 性質の異なる情報が、ひとつのテーブルに同居している ◦ 更新タイミング・更新主体・守るべき不変条件・ライフサイクル ◦ これが違えば、物理的には1テーブルでも別の関心事 基本情報 掲載審査 インボイス事業者 （今回のターゲット） その他 色が変わるところが、意味が変わるところ 4
5. 課題：HostRepository#save で保存処理をカバー • 1回の save が、hosts の全カラムを UPDATE/INSERT していた ◦ • どの属性を本当に更新しているのか、コードから読めない、レビューで見切れない 影響範囲が、過度に大きい ◦ 実装の不便さに見えるが、これは設計のサインだった 5
6. あれ？わたしのドメイン大きすぎ・・？ 実装の違和感は、 ドメイン境界が曖昧なサイン 6
7. インボイス事業者情報は、独立していた • ライフサイクルが違う ◦ • 参照される文脈が違う ◦ • ホスト情報登録後、別の導線から登録される 請求・会計の文脈で読まれる情報 守る不変条件が違う ◦ 登録番号の必須性など、ホスト基本情報とは別のルール だから、別のドメインモデルとして扱おう 7
8. どう分けたか：DBはそのまま、Repositoryを分ける • Entity と Repository を2つに分けた ◦ Host ／ HostInvoiceRegistration HostRepository HostInvoiceRegistration Repository 基本情報・掲載審査など ※ここも分けるべきですが今スコープはそのまま インボイス事業者情報 hosts テーブル（変更なし）― 触るカラムが重ならないようにした アプリ層からは、異なる文脈として永続化されているように見える 8
9. ルール • • カラムの所有権を決める ◦ 各Repositoryは、自分のカラムしか読み書きしない ◦ 無関係なカラムを巻き込まない 同時更新の衝突はロックで守る ◦ ただしロックの粒度は行単位。ここは今も検討中 9
10. やってみてどうだった：よかったこと • カラムの所有権が決まった ◦ • 誰がどのカラムを触っていいかが定義された 影響範囲が閉じた ◦ レビュー観点が絞れる ／ 単体テストの書きやすさ向上 10
11. 悩み：どう境界を定めるか • • 境界は「意図」である ◦ どういう目的でこの抽象を切り取るか。根拠はドメインの言語と不変条件にある ◦ これはどっちかな？という悩みは常につきまとう ▪ AIやチームと対話しよう。悩んだ分だけ解像度上がる ▪ あとから変えてもいい。育てよう AIとは相談できる。最後の決めは人間がやる ◦ 壁打ち・抽象化・整合性の検証・実装は任せられる。 線をどこに引くかは人間の仕事 11
12. どこまで分けるか：迷ったときの3観点 • 単体で意味のあるドメインか • 不変条件が独立しているか • 同一カラムを複数モデルが触らない設計にできるか 12
13. まとめ • 分割の是非を決めるのは、テーブル構造ではない ◦ ドメインの意味 ／ 不変条件 ／ 更新責務の境界 • 先にドメイン境界を定義すれば、分割は結果として決まる • 境界は意図。AIとは相談できるが、最後の決めは人間がやる 13