Внешний идентификатор как идентификатор домена

Question

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

«Проблема» у нас есть идентификация «хорошего» кандидата как идентификатор домена для совокупности.

Похоже, у нас есть 3 варианта:

1. Генерировать идентичность домена (UUID или DB-sequence ...);
2. Используйте внешний ID как идентификатор домена, который поставляется вместе со всеми данными из внешнего источника.
3. Используйте идентификатор внутреннего домена И внешний ID как отдельный идентификатор, который «может» использоваться для операций поиска; внутренний идентификатор всегда ведущий

О Внешнем-ID:

• Это 100% гарантируется ID будет не изменится
• Идентификатор всегда удался самой внешнего источник
• Другие домены в нашей системе могут использовать ext ernal-идентификатор для поисковых операций

Особенно последний пункт выше убедили нас в том, что внешний-идентификатор не является инфраструктурной проблемой, но на самом деле принадлежит к домену.

Какой вариант выбрать?

** UPDATE **

Может быть, я не ясно, о термине '3th партии'.
Фактически внешний источник - это наш клиент, который активно работает в автомобильной промышленности.
Наше приложение использует основные данные клиента для выполнения нескольких «вещей». У нас есть несколько Локальности контексты (BC), как 'Управление клиентами', 'Survey', 'Назначение', 'Техническое обслуживание' т.д.

Наш клиент посылает нам 'Задачи', которые описывают что-то нуждается в этом. Это «что-то» может быть:

• «пусть клиент X полный обзор Y»
• «график/отменить назначение для клиента X»
• «автомобиль X для клиента Y запланирован на обслуживание в позиции XYZ '

Эти «Задачи» всегда имеют «идентификатор задачи», который гарантированно будет уникальным. Мы сохраняем все входящие «Задачи» в нашей базе данных (активный стиль записи). Все возможные действия над задачей сопоставляются с событием домена. (Несколько BC могут быть заинтересованы в одной и той же задаче)

Каждый BC содержит одно или несколько агрегатов, которые распределяют некоторые события домена другим BC. Например, когда назначение отменяется, происходит событие домена, обслуживание прослушивает это событие, чтобы выполнить некоторые действия.

Однако наш клиент ожидает сообщения после каждого действия, связанного с Задачей. Поэтому нам всегда нужно использовать «идентификатор задачи».

Суммируя вещи:

• Задачи имеет целевой идентификатор
• Задачи может быть связана с несколько BCs
• Каждого BC посылает некоторое «результат сообщение» клиент с соответствующим целевым идентификатором
• задачи идентификаторы распределены по событиям домена
• Мы продолжаем каждый (внутренне) сохранялся задача уточненного

Надеюсь, я был достаточно ясен об использовании внешнего id (= task-id) и наших различных BC.

Answer 1

У меня возникло чувство, что вы должны управлять своей собственной личностью и не полагаться на стороннюю службу для этого, поэтому вариант 3 выше. Трудно сказать без контекста. Что такое сторонняя система? Каков ваш домен?

Вы бы переключили стороннее обслуживание?

Вы говорите, что другие части вашего домена могут использовать внешний идентификатор для запроса - что они запрашивают? Ваши внутренние системы или сторонняя служба?

[Update]

на основе новой информации, это звучит как CorrelationId. Я бы сохранил его вместе с другой информацией, относящейся к агрегатам.

Answer 2

Как правило, я бы наложил вето на использование номера последовательности БД в качестве идентификатора; модель домена должна быть независимой от выбора настойчивости; модель домена записывает идентификатор в базу данных, а не наоборот (если БД хочет отслеживать порядковый номер для своих целей, это нормально).

Я неохотно использую внешний идентификатор, хотя он может иметь смысл в некоторых обстоятельствах. У данного объекта, такого как «Клиент», могут быть представления в нескольких различных ограниченных контекстах - может иметь смысл использовать один и тот же идентификатор для всех из них.

Мое значение по умолчанию: я бы использовал для name based uuid, используя внешний идентификатор как часть семени, что дает простое сопоставление от внешнего к внутреннему.