ドメイン駆動設計 モデリング/実装ガイド
https://scrapbox.io/files/64f881b9444ac2001b4b0800.png
実務で DDD をやってみると難しいと感じ実践的な例を求めて購入
面白くて 1 日で読んだ
物理本を買うと PDF がついてくるのが良い
印象に残った
DDD に準公式な定義があるのを知らなかったので、しれて嬉しい
今度読もう
良いモデルとは、問題を解決できるモデルである
見た目に拘らない(戒め)
モデルは生成、変更まで validattion をとして、常に正常なインスタンスが存在するようにする
例外なやつは seed とかでごまかすしかないんか?
モデルはコンテキストごとに違うことを容認できるのか
となるとフロントエンドで DDD をやる場合、フロントエンドで特化した Domain model を作って良い…?
Q&A が役に経ちすぎるな
DB への意識とか共感しかない
マイクロサービスでの DDD の話はおもろい
リポジトリは List のように扱う
例えとしてはおもろい
関連モデルを ID で持たせるかかインスタンスで持たせるかは、それらが同一の集約に属するかで決める
Repository の Interface を usecase 層ではなく domain 層に置く理由
Repository はどの集約の単位で永続化するかを決めるものなので、domain 知識に相当するから
あとは普通に domain service から参照できなくなる
<< 第 8 章 CQRS >>
これを見るためだけにこの本を買ったと言っても良い
期待
DDD で CQRS を導入するモチベーション
「集約単位での Repository」に従った場合、複数の model を横断するような画面を作るときに Repository の実装が煩雑になり、パフォーマンスが悪化したりいろいろつらい
Query Model が Usecase にある理由
Query Model が画面(というか usecase ?)に依存したものだから
Query Model は必要になったときに導入するでもいいらしい
肝心の domain model で参照されないコード問題の答えは見つからなかった…
しばらく考えてだめだったら著者に質問するか
レイヤーごとにバリデーションが重複する問題
面白かった
あと 2 回ぐらい読めば色々理解できそう
疑問に思った
集約
集約単位で Repository から R/W するは、フロントエンドで DDD をするときも必要?
バックエンドが validate してくれはしそうだけど…
でも in memory に変な状態のモデルが生成されるリスクはあるよね
「仕様」と「ビジネスロジック」の明確な差が微妙
Entity の一部の更新をしたいときに、その一部を Repository に渡すのではなく、全体を渡すのはなぜ?
本書では整合性を保つためというけれど…
Entity が validattion に引っかからず生成、変更できている時点で整合性は担保できているのでは
とはいえ Entity の一部ではなく、普通に value object を repository にそのまま渡してしまうリスクはあるので、やはり repository の引数は集約単位でいいのかも
それでいうと update(currentModel, newField) という Repository の Interface はだめかも
だけど newFiled が永続化する前の不完全な存在の可能性もあるよな…… → ここに純粋な domain model を入れられない
やはり seed を定義スべき?
たしかに Repository が入力の内容を検証するのはおかしくて、整合性も含めて、信じれるものだけを渡すべき
Usecase が Domain object を返すのはだめ?
本書ではデメリットとして domain object に表示用の method が生えてしまうことを示している
しかし程度の差はあるにせよ「どう表示したいか」を domain 知識として持ってはいけないのか?
CQRS
参照に使用するモデルと更新に使用するモデルを分離する
この「モデル」ってなんだ?domain model ? それとも一般的なモデル?
更新系モデルは、ドメインオブジェクト (エンティティ、値オブジェクトなど) をそのまま使用します。
参照系モデルは、特定のユースケースに特化した値の型を定義します。
更新系モデルのある property が readonly だった場合、それは実行されない property とならない?
そんな proptery は存在し得ないのか…?
でも例えば DB が勝手に付与するような値を domain として定義したい場合、それは readonly な propterry になりうるのでは
そして readonly な property は query model 経由でしか参照しないから…
仕様を表す役目としてはいいが、使われない(= 実行されない)コードがあるのが気になる