本記事にまとめました。>>モデリング結果(drawio)>>モデリング対象(データベーススペシャリスト2021秋午後I問1)ドメイン駆動設計の練習モデリング編についてはこちらにまとめています。松岡さんの「サンプルコード&FAQ」、「モデリング/実装ガイド」を参考にさせて頂きました。サンプルプログラムの作成及びテストコードの作成は本をなぞった形になります。(その点お含みおきください)2022/03/22追記ドメイン駆動設計でモデリング〜コーディング〜テストコード作成までのまとめ記事を作ったので興味がある方は是非みてください。ドメイン駆動設計でモデリング〜サンプルプログラム・テストコード作成(まとめ記事)エンティティと値オブジェクトの違いとは??エンティティと値オブジェクトの違いについて本ではこのように述べられていました。エンティティと値オブジェクトは、ドメインモデルを「モノ」として表現するオブジェクト「モノ」として表現するオブジェクトが2種類ありますが、この違いは何でしょうか?それは、同一判断の方法です。エンティティは同一判定を識別子で行い、値オブジェクトは同一判定を保持する値で行います。他の属性例えばニックネームとかが変わっても、ユーザIDで一意に特定するので同一ユーザと判断できる。金額オブジェクトを比較する際は金額オブジェクトが持つ金額の値によって同一金額かどうか判断できます。エンティティは後から変更可能で、値オブジェクトは一度作成したら不変なものとして扱います。ユーザの名前などは後から変更できる想定だけど、10円として値として生成した値オブジェクトは何があっても10円のままで、20円にしたければ、20円の値オブジェクトを別途生成するイメージ。エンティティと値オブジェクトはこれら違いを意識してモデリングしたり使い分ける必要があります!!値オブジェクトをなぜわざわざ使うのか??使うメリットは??僕が値オブジェクトを使うかどうかの判断をする際は、以下メリットのために利用します。誰が作ったかわからないけど、スケジュール的にもそれをブラックボックス的に使うしかない。みたいなケースを妄想してください。そんなケースないか・・・・こういう、オブジェクトがどこかで変更されちゃうかも??という心配が値オブジェクトにはなくなります。(そもそも副作用ありまくり巨大メソッドを直せばいい話ではあるのですが、、、)また、金額を取り扱うシステムでシステムとしては0~1,000,000円までを取り扱えば良いのに、int型で定義すると-2147483648~2147483647を扱える状態になります。貰うべき金額が逆に支払うような予期せぬ事態が発生したり。いったことに繋がります。コンストラクタで扱う金額の範囲をチェックしてやれれば、金額の範囲のチェックを1箇所だけに集められ、尚且つマイナスを入れられて予期せぬ事態に陥るといったことも避けられます。僕はこれらメリットがあると判断した場合のみに値オブジェクトを使うようにしています。〇〇IDだから必ず値オブジェクトにしよう!!とかはせず、モデリングを進めて必要に応じて値オブジェクトを使うようにしています。作成したエンティティと値オブジェクトとそれらのテストコードについて紹介していきます。支払エンティティモデリングでいう支払集約のところになります。支払明細がないようなオブジェクトは生成できないようにしました。価格値オブジェクト>>該当ソース(github)システムで取り扱う金額の範囲を値オブジェクトインスタンス化の際にチェックするようにしました。こちらもシステムで取り扱う金額の範囲外の値オブジェクトは生成できなくしています。支払エンティティのテストコード>>該当ソース(github)支払エンティティのオブジェクト作成時のチェックをテストしています。本と同じようにする場合、デフォルト引数がないせいでオーバーロードで結構記述が必要でした。(Kotlinのよさを1つ知りました、、、このサンプルコードを後でKotlinでも書いてみようと思ってます)価格値オブジェクトのテストコード>>該当ソース(github)こちらも支払いエンティティと同じく価格オブジェクト作成時のチェックについてテストしています。エンティティや値オブジェクトのサンプルコードを作成してみた感想や気付き本の通りモデリングを先に実施してドメインモデル図があって、そこからエンティティを作成するとモデリングの結果がきれいにソースコードにマップされていく感じが体験できました。この方式でモデリングしてからその通りにエンティティに紐づくドメインルールをエンティティに記載できれば、あちこちビジネスルールが散らばることが避けれると思います。現場で昔から僕がよく見てためちゃくちゃ長い上から下に諸々チェックのやり方がずらっと書かれたエクセルの設計書だと、それをベースに作成するプログラムもどうしてもビジネスルールを神Serviceで上から下にずらっと書いてしまいたくなりますが、ドメインモデル図をベースにプログラムを書くと、ドメインルールは紐づくエンティティや値オブジェクトに書くのが自然の流れになると思います。(結果ドメインルールが1箇所に纏まる)ドメインモデル図のあのフォーマットの良さが、プログラムを実際に書くことで改めて実感することになりました。少ない資料でよりプログラムに自然に落とし込める流れが作れそうな気もします。コメントをキャンセルメールアドレスが公開されることはありません。コメントデータの処理方法の詳細はこちらをご覧ください。