前回の記事
【ミライトデザイン社内勉強会#22】「IDDD本から理解するドメイン駆動設計」輪読会~第13章「分散システム設計」~ - Qiita
実践DDD本 第14章「アプリケーション」～ドメインモデルを利用するクライアント～ (1/3)：CodeZine（コードジン）
ユースケースに最適化したクエリによる取得はDTOではなく値オブジェクトに設定して返すとあるが、なんのために値オブジェクトにしているのかがよくわからない
- Valueオブジェクトのコンストラクタに整合性チェックのためのアサーションが書いてある前提なのかも
- DBから再構築する際にはチェックはいらないことの方が多い（生成するときにチェックしているので、再構築の時はチェックはいらない前提）
- 値オブジェクトとDTOの違いは、DTOはDBに存在しない値は存在しないが、値オブジェクトは振る舞いを持っている
- 値オブジェクトにあるメソッドを使えば、DBにない値も取得できる
- 例えば、DBには税抜き金額と税率しかないが、値オブジェクトの場合は、税込の金額を計算して返す。みたいなこともできる。
- 値オブジェクトにあるメソッドを使えば、DBにない値も取得できる
- 値オブジェクトをUI層で使用することで依存ちゃってないか？
- p2のコラムで詳細を書いてる。
（2）複数の集約へ参照を保持するDPOを返送で集約の保持する情報をDTOアセンブラに公開する必要があるかもしれません。とあるがそれを避ける理由って？
- 集約内部の情報を外部にできるだけ公開したくないからかも
- 集約にDTO作るメソッドを作れば、外部に公開しなくて済むよってことを言ってる気がする。
- 集約がDTOに依存している方がまずいのでは？
- 集約と一対一のオブジェクトをドメイン側で作成すれば、DTO毎に集約側にメソッドが増える。みたいなことはなくなる。
プレゼンテーションモデルのイメージがよくわからない。Vue.jsのstateみたいな感じ？
- どっちかというとhooksに近い気がする
- DTOとの違いは振る舞いを持っていること
- 画面依存のメソッドを持っているモデル
- メッセージを赤にするとか
- ログインしている場合は、メッセージを変えるとか
- UI専用のロジックを持ったモデルの様なもの