DDD - Создание и рефакторинг полей идентичности сущностей

Question

Мы изучаем DDD и оцениваем его использование для системы, поддерживаемой устаревшей системой и хранилищем данных.

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

Но мы не уверены и не уверены в методах идентификации и идентификации личности. Унаследованное хранилище данных не имеет первичных ключей, вместо этого используются составные уникальные индексы для идентификации информации.

В настоящее время мы создаем нашу модель как объекты Value, которые должны быть объектами (желая добавить поле "Длинный идентификатор" к каждому), или мы редко используем комбинацию атрибутов, используемых в уникальных индексах, в качестве поля id. Нам кажется очевидным, что модели Entity должны иметь поля id.

Вот мои конкретные вопросы:

• Мы хотим, чтобы наши новые блестящие сущности теоретически имели поля "Длинный идентификатор". Можно ли не добавлять это поле сейчас, поскольку это не дает нам никакого значения, поскольку хранилище данных бэкэнда не заполнит или не поймет это поле?
• Можно ли с помощью DDD хранить идентификационную информацию и проводить ее рефакторинг, как мы надеемся, хранилище данных изменится в соответствии с нашими потребностями.
  • Если это так, является ли абстракция идентификации от сущностей хорошим подходом (я имею в виду интерфейс Identifiable или KeyClass для каждой сущности? - здесь нужен какой-либо хороший совет...)
• Этот вопрос может выходить за рамки DDD, но мне интересно, может ли рефакторинг идентификации оказать влияние на несколько уровней систем (например, REST api может измениться с /entity/id_field/id_field/id_field на / entity / new_long_id)

и другие вопросы:

• Как мы можем использовать унаследованную информацию для нашей растущей модели полированного домена, с меньшими затратами на идентификацию?

• Или это плохо и не ценно желать Long ID для нашего домена в любое время жизни проекта?

• Как мы можем реорганизовать управление идентификацией?

Обновить:

• Является ли идентичность важным аспектом DDD или это инфраструктурный аспект, который может быть подвергнут рефакторингу, поэтому мы не должны тратить на это больше времени?

Answer 1

Используйте любой идентификатор, который соответствует вашим потребностям, но будьте реалистичны и откровенны в отношении стоимости и последствий выбора неправильного. Целесообразно назначать идентификаторы извне и просто хранить их вместе с другими битами информации (независимо от формата (guid, long, uuid)). Независимо от того, нужно ли проводить рефакторинг идентичности mgmt, больше нужно провести анализ затрат / выгод. Это даже вариант с устаревшей системой, и в какие сроки будут две боковые боковые клавиши? Почему вы даже повторно используете один и тот же хранилище данных? Почему бы не разделить его, чтобы вы могли иметь параллельные хранилища данных (в худшем случае даже синхронизировать данные между ними, предпочтительно в одном направлении)? Попробуйте вертикальную нарезку вместо горизонтальной. НТН.