設計判断の理解アプリの要件的な理由も考慮されているかもしれない。アプリケーションの問題を公家庭に解決できるか確認する。↑それがエンティティ時間が経過しても変わらない物がエンティティとして捉えた。営業所AからBに移した場合は、追跡できないとまずいかな?オブジェクトの属性が普遍であるものは、値オブジェクトの特性なぜ配送仕様だけ値オブジェクトなのか?値オブジェクトは、情報の共有ができる。貨物に対しては、共有できる情報なので、値オブジェクトになる。ドメインの中で需要なプロセスや変換処理をまとめたインターフェイスただし、エンティティや値オブジェクトの責務から外れるものインフラ層は、イメージしやすい。ドメインレベルのサービスは、イメージしにくい。複数のモデルが関与するサービス同じクラスでも別インスタンスでやり取りをするもの。2つの銀行口座を操作するもの。口座の送金とかとらえ方が難し。システムの概念を伝えやすく分割したものシステムに影響されるにモジュールの詳細を伝える。特定のオブジェクトへの操作の詳細を隠蔽して扱いやすくする。CRUDのCは入らない。Cはファクトリの役目。19:33復習のディスカッション・コードに落としてみないと、実感がわかない。・今後の勉強会で、コードを書いてみたい。P154Q.トランザクション制御をクライアントゆだねるというのは、一般的なのか?A.JDBCをべたで使ったりすると、リポジトリの外に出してしまう。JTAを使って、サービスに持ってくると、アプリケーションのサービスが一つのトランザクションになることが、一つの理想。リポジトリの操作は、シンプルなはず。使われ方によって、操作を用意する。関係データベースに合わせてオブジェクト設計する。1.データベースとのマッチングを簡素化するために、モデルに制約を設ける。シンプルであることが重要。2.データベースが、別なシステムのために設計されている場合レガシーや、外部のシステムから来ている場合モデリングの理想を崩した・・奇抜な変更ユビキタス言語で、オブジェクトモデルと関係モデルのコンポーネントを結びつける。3.データベースは、オブジェクトを格納する以外の役割を果たしている。ドメインモデルと関係ないスキーマが格納されている。ドメインモデルと、データベース上のデータに乖離が発生することがある。意図的にドメインモデルとデータベーススキーマを分ける場合は、間に層を設けるとかしたほうが良いかもしれない。・リポジトリに対して問い合わせる。・クライアントのコードは、リポジトリの実装を無視するが、開発者はそうではない。・フレームワークの範囲内で作業する。