ドメイン駆動設計と相互依存性

こっつん @cttsn

しかしちゃんとドメイン駆動設計すると関連テーブルが使いづらい…

かとじゅん @j5ik2o

@pnkts う？相談のりましょうか？

こっつん @cttsn

@j5ik2o https://t.co/CM8DigG9qZ かなり参考にしてます！ 例えばユーザは複数グループに所属でき、ユーザの所属一覧とグループのユーザ一覧と両方欲しい場合、所属エンティティの属性にユーザとグループ内の値オブジェクトをコピーすればいい感じですかね…

かとじゅん @j5ik2o

@pnkts あ、だいたいわかります。ユーザはグループではないのでグループを表す属性は持ちませんし、その反対も同様です。なので、ユーザには所属する複数のグループへの参照を持つか、グループが所属される複数のユーザへの参照を保持するかという話になりますね、たぶん(続く

かとじゅん @j5ik2o

@pnkts まず相互依存の関連は維持管理がシビアなので最初から前提にしないで一方向になるようにしましょう。つまり便利な関連は排除し本質的な関連だけにする。仮にユーザにグループへの参照があるとした場合で説明すると。

かとじゅん @j5ik2o

@pnkts ユーザとグループはそれぞれ独立したグローバルな識別子を持つエンティティであり、集約です。ユーザには所属するグループへの参照としてグループIDの集合を属性に持ちます。このグループIDの値はユーザの値です。なので集約内の属性としてIOすれば言い訳です。

こっつん @cttsn

@j5ik2o 識別子自体は参照ということなので集約間で共有できるわけですね。モヤモヤしていたところが解消されました！ありがとうございます！

かとじゅん @j5ik2o

@pnkts あ、前提としてユーザとグループは独立した識別される概念なのでエンティティとしています。

かとじゅん @j5ik2o

.@pnkts 言語上の参照で保持しちゃうと集約内部か外部かが見分けがつかないので基本識別子を使うしそれはランタイム表現なんですよ。集約であるエンティティはランタイム上のライフサイクルを超えうるのでたとえばストレージなどに存在する場合は表現できなくなります。なのでIDがよいです。

こっつん @cttsn

@j5ik2o ユーザが値オブジェクトだったら匿名性バッチリですね！ つまり所属というエンティティを新たに作るとユーザとグループの境界が曖昧になり不味いので、どちらかに片方の参照を集約しておくということですかね。

かとじゅん @j5ik2o

@pnkts ユーザは値オブジェクトになりますか？見分ける対象の場合はエンティティにしないとだめですよ。 http://t.co/8ZKZiFGmoi

こっつん @cttsn

グループのテーブルの行にユーザID列をシリアライズして格納するのは嫌なのでlazyloadingで参照をIOすればいいのか

かとじゅん @j5ik2o

@pnkts 実装から考えるのではなく、ドメイン層というのは概念から考えないとダメなんですよね。ユーザが値オブジェクトかエンティティかはどういう概念のものを扱おうとしているか最初に整理しないといけませんね。実装都合で、やーこれはVOだな、Eだなというものではないのでw

こっつん @cttsn

@j5ik2o たしかに順序がありますね。モデルと設計は一致させなければならないのに早々と実装に振り回されると釣り合いが保たれないです。

かとじゅん @j5ik2o

@pnkts 仮にユーザがVOの場合は見分けが付かなくなります。ユーザを認証するようなアプリケーションの場合はそれぞれのユーザを識別するわけですが、VOだとこれが不可能になりますね。最初にユーザとは何か？とかどういう使われ方をするモデルなのかを定義しないといけませんね。

こっつん @cttsn

@j5ik2o ユーザのように明らかに要識別の物はわかりやすいですが、今までRDBMの機能に縋ってた身としては関連テーブルまでもEと錯覚してしまいがちです。

かとじゅん @j5ik2o

@pnkts みんないい感じにERD脳にチューニングされているので一旦忘れて考えた方がいいです。DDDにおいては。

かとじゅん @j5ik2o

@pnkts class User(id: UserId, groupId: GroupId, name: String); class Group(id: GroupId, name: String);

かとじゅん @j5ik2o

@pnkts UserRepository#findById(uid): User; UserRepository#findByGroupId(gid): Seq[User]; GroupRepository#findById(gid);

こっつん @cttsn

@j5ik2o １対多ならgroupIds: Seq[GroupId]とすればいいですかね

かとじゅん @j5ik2o

@pnkts そそ。class User(id: UserId, groupIds: Seq[GroupId], ...)

かとじゅん @j5ik2o

@pnkts その属性がいい感じにRDBMSのテーブルにマッピングされるように考えればいいですね。UserRepository#findByGroupIdを可能にするならばインデックスを効かせたいのでUSERテーブルとUSER_GROUPIDSテーブルみたいな感じにするかな。

こっつん @cttsn

@j5ik2o かなりすっきりしてきたと思います。集約のルートのみにしかリポジトリが存在しないことでクライアント側から好き勝手アクセスして混沌化することを防げるのも納得してきました

かとじゅん @j5ik2o

@pnkts 概念があって実装クラスって感じなので、最初の概念がデカいと集約自体も実装がデカくなるので、I/Oもボトルネックになりやすいと考えるとよいですー。実は二つのエンティティが隠れているのでは？ということで考え直すことで性能もよくなったりします。

こっつん @cttsn

@j5ik2o ありがとうございます。リポジトリ層で完結できればクエリのチューニングで対応してそもそも規模が大きすぎるならモデルの見直しを意識していこうと思います。