Домен DDD против Агрегатов

#domain-driven-design

#дизайн, управляемый доменом

Вопрос:

Я пытаюсь разобраться в DDD.

Допустим, у нас есть веб-сайт доски объявлений о вакансиях, где Organisations можно размещать вакансии и Applicant подать заявку.

Правильно ли я понимаю, что будет Recruitment домен с:

  • JobPost и JobPostApplication как агрегаты
  • HiringOrganisation и Applicant как сущности их соответствующей совокупности
 Recruitment
└── Model
    ├── Entities
    │   ├── Applicant
    │   └── HiringOrganisation
    │   └── Location
    ├── ValueObjects
    │   └── Salary
    │   └── EmploymentType
    ├── JobPost
    └── JobPostApplication
  

Если да, то как бы:

  • Applicant относятся к User из Auth домена
  • HiringOrganisation относятся к Organisation в Organisations домене

Ответ №1:

как заявитель будет относиться к Пользователю из домена Auth Организация найма относится к Организации в домене Organizations

Как правило: общие идентификаторы. Некоторое значение (часто непрозрачный токен, например UUID) является общим для обоих контекстов, так что мы можем сопоставлять сообщения, в которых говорится об «одном и том же», в разных пространствах, где данные меняются с течением времени.