Как объединить данные из разных ограниченных контекстов в DDD

Question

Я новичок в DDD, и мне нужна помощь.

Пример:

У меня есть два ограниченных контекста Exams и Courses. В контексте «Экзамены» имеется элемент Student, в котором содержится информация о студентах, сдающих экзамен. А в контексте «Курсы» есть сущность учителя, которая содержит информацию о преподавателе, преподающем курс.

У меня также есть AuthService (чисто CRUD), который используется для аутентификации и авторизации пользователей. AuthService имеет сущность Accounts, которая содержит такую ​​информацию, как имя пользователя учетной записи, адрес, номер телефона и т. Д.

Объединяя их всех, оба Student и Teacher имеют учетные записи, поэтому их информация уже доступна.

У меня есть пара вопросов по этому поводу.

1. Является ли анти-паттерн в DDD хранить AccountId в организации для учеников и учителей? Если это не анти-паттерн, в какой момент можно собирать информацию об учетных записях студентов с помощью AccountId, In repository или в контроллере API или использовать вызовы RPC / API.
2. Можно ли копировать данные, необходимые из учетной записи, в организацию учащегося или учителя?

Answer 1

Я предполагаю, что AuthService находится в своем назначенном ограниченном контексте для аутентификации, и Учетные записи также находятся в том же ограниченном контексте.

Вот мои ответы:

Это анти-шаблон в DDD для хранения AccountId в сущности «Ученик и учитель»?

Вы можете хранить AccountId в сущностях «Ученик и учитель».Это не анти-паттерн, а скорее противоположность - это то, как разные агрегаты ссылаются друг на друга, сохраняя идентификатор других агрегатов.

Если это не анти-паттерн в какой моментМожно ли собирать информацию об учетной записи учащегося с помощью AccountId, в репозитории или в контроллере API, или мы должны использовать вызовы RPC / API.

Я не понимаю, какой именно репозиторий вы имеете в виду, дляАккаунт, студент или учитель?Каждый корень агрегата имеет свой собственный репозиторий, и этот репозиторий отвечает только за хранение этих агрегатов.Он не знает и не запрашивает другие агрегаты.Если вам нужно запросить другие ограниченные контексты, сделайте это на уровне приложения - если операция, которая делает это, не относится к области.Если это проблема домена, то сделайте это на уровне домена, представив другой ограниченный контекст как службу домена (интерфейс).RPC / API - это деталь реализации вызовов взаимосвязанного контекста, и вы можете использовать любой способ для запроса другого ограниченного контекста, если детали реализации не проникают в доменные уровни.

Можно ли копировать данные, необходимые из учетной записи, в организацию учащегося или учителя?

Это тоже нормально.Вы делаете это для достижения большей доступности по цене возможной согласованности.В таком случае ограниченный контекст / сущность, которая содержит информацию от другого, подтверждает, что копия данных может устареть, но это приемлемо с точки зрения бизнеса.

Дайте мне знать, если возникнут вопросы.Я долгое время практикующий DDD.

Answer 2

Я думаю, что вы ошибаетесь.То, что связано с Authentication, не должно находиться на уровне домена.Student и Teacher равны entity, но Account в AuthService не равно entity.Насколько я вижу, вы хотели бы добавить новый Student или Teacher, используя некоторую информацию, полученную из Account, но для этого вы должны передать эту информацию, выбрав User Account info и передать ихStudent или Teacher класс для создания экземпляра нового объекта.

По второму вопросу, в зависимости от нашей деятельности, у вас могут быть те же свойства.DDD просто подчеркните, что вы должны использовать ubiquitous language для именования сущностей и методов, и не имеет значения, что вы используете те же свойства.