まえがき
読みかけ。
本格的にDDD？を導入する気概はないけど、参考になる箇所は多々あるなという印象。
せっかく読むので、参考になった個所をメモに残しておくことにした。
（すでに半分くらい読んでしまったが。。）
ドメインモデルとは
データとロジックを持つクラス
ドメインモデルのメリット
・データとロジックを同じクラスに持たせることで、同じロジックをいろんな個所に実装するのを防げる。
・ロジックがどこに書いてあるかわかりやすい。
・ドメインモデル変更時の影響範囲が狭い
・データとロジックを同じクラスに持たせることで、クラス本来の力を最大限に活かせる。（基本的にSpringBootのServiceクラスでは状態を持たないので。。）
ドメインモデルの開発
関心ごとを小さな単位に分けて、その狭い範囲で必要なデータとロジックを集めることを繰り返す。
クラス名やメソッド名は業務の名前と一致させる。（HowではなくWhatということかな。）
業務を学びながらドメインモデルを成長させていく。開発の初期段階では開発者はドメインモデルを設計するための知識が不足している。（自分のPJに適用するのは難しいが、開発の初期段階では業務知識が不足しており、業務知識がアップグレードされるにしたがってドメインモデルを見直すという視点を持つことは大事だなと感じる。）
業務知識を引き出す
業務の専門家の業務知識は言語化されていない。
そのため会話で引き出す必要がある。
会話の中で出てくる「聞きなれない言葉」「使い方に違和感がある言葉」が業務を理解する手掛かりとなる。
業務の専門家と会話し、業務用語を習得することがドメインモデルを設計する活動の基本となる。
「聞きなれない言葉」「使い方に違和感がある言葉」は、聞き逃したり、自分の知っている言葉に変換したりしてしまう。そのため自分がドメインについて理解したことを書き出し、言葉の使い方が適切か専門家に見てもらう。
こういうやりとりをしながら専門家と同じ意味や言い回しで使える言葉を増やしていく。
業務の経験者にとって自然な言い回しになって、かつ、それが業務の重要な関心ごとなら、業務の専門家の反応が積極的になってくる。
この段階になれば、よいドメインモデルを設計できる。
業務の専門家と話す前に
いきなり業務の専門家と話をしても話が通じず時間の無駄となることが多い。
まずは自分なりに業務の勉強をする必要がある。
・業務の用語に慣れる（マニュアル、書籍など）
・業務について大まかに理解する（書籍、画面、帳票など）
⭐この本の応用方法
現実的にどうやって応用するかなと考えた場合、以下のような感じになるかと思う。
domainsというフォルダを用意しておき、
・データを保持するクラス
・データと業務ロジックを保持するクラス
を作りたくなった時は、そこに作成する。
こうすることで、DataクラスやDtoクラスを作らなくてよくなるし、業務ロジックの場所が集約される。
ドメインオブジェクトのfromEntityメソッドでDB検索結果をドメインオブジェクトのインスタンスに変換するという感じかな。
Entity、Form、Request、Response、EnumsあたりはDomainとは別でフォルダを作成して、ロジックもそれらに書く。
Domainフォルダはあくまで業務ルールに関するデータ型を格納する。
どれにも当てはまらないデータ型を作りたいときはDto or Dataフォルダを作ってそこに格納かなあ。