エンティティ(entity)

「属性は変わっているが、同一性が保たれているもの」をエンティティとします

どういうことかというと…

人間は生まれてから死ぬまでに成長したり、取引を行ったり、名前が変わったりしますが、一度生まれた人間は何年経とうと別の人間になることはありません
こういうもののことをエンティティとして区別します

エンティティは同一性を保つためにユニークな値(識別子)が必要になります
○○番号、○○IDのようなものが必要です

値オブジェクト(value object)

「同一性を追跡する必要が無いもの」を値オブジェクトとします

どういうことかというと…

「100」という値はどこまでいっても「100」です
元からある「100」と新しくできた別の「100」は区別しません
「100」は「100」です
こういうもののことを値オブジェクトとして区別します

値オブジェクトは不変になるようにする必要があります
不変オブジェクトについては下記を参照してください
不変オブジェクトって何？【作り方も解説】

サービス(service)

ほとんどはエンティティや値オブジェクトとして区別されますが、それ以外のものもいくつかあります
その内のひとつがサービスです

ドメインにおける重要なプロセスや変換処理がエンティティや値オブジェクトの自然な責務ではない場合、その操作はサービスとして宣言される独立したインターフェースとしてモデルに追加すること
モデルの言語を用いてインターフェースを定義し、操作名が必ずユビキタス言語の一部になるようにすること
サービスには状態を持たせないこと

つまり、サービスとしてドメイン層にインターフェースを用意する、ということです！
このインターフェースから他システムの呼び出しを行ったりします

○○サービス、○○マネージャーという名前が付けられることが多いみたいです

集約(aggregates)

ドメイン層にあるオブジェクトに境界線を引いて、その中で一番偉いオブジェクトを決めます(これを集約ルートと言います)
集約内のあるオブジェクトを変更したい、と思った時にはその集約の一番偉いオブジェクト(集約ルート)に問い合わせて変更を行います

このようなルールを用いることで、集約ルートが集約内のオブジェクトの変更の一貫性を担保するため、気づいたらオブジェクトが変更されていた…という事態をなくすことができます

集約内のオブジェクトの管理を集約ルートで一括で受け持つイメージです

ファクトリー(factories)

あるオブジェクトを生成する責務をそのオブジェクトに任せるのは適切でない場合が多いです
そのようなときにファクトリーをドメイン層に作ってあげると役に立ちます

ここで問題になるのはどこにファクトリーを配置するか、ということですがそのオブジェクトをコントロールさせたい場所に置くことが多いようです
集約ルートに配置してしまうことも多いようです

ファクトリーは新しいオブジェクトの生成の他にも、一度DBに格納したオブジェクトの再構成に使うことができます

リポジトリー(repositories)

各オブジェクトがDBからデータを取り出してオブジェクトの再構成を行おうとすると煩雑になり、集約のルール(集約ルートを経由させること)やカプセル化が壊れてしまいます
更に、各オブジェクトはデータアクセスのことしか考えられなくなってしまうため、モデルの持つ本来の役割が薄れてきてしまいます

それを防ぐためにDBアクセスを責務とするリポジトリーを作ります
大抵の場合集約ルートに紐づく形で作られます

まとめ

駆け足でしたが、今日は疲れてしまったのでこのくらいで…ｗ
次回はしなやかな設計について解説していこうかなと思います

DDDについてのまとめページ