В ходе обсуждения у меня возник следующий вопрос. В банковском домене существует совокупный корень, Учетная запись, идентифицируемая по номеру учетной записи. Предположим, что в какой-то момент банк решил изменить всю учетную запись с 8 цифр на 12 цифр по некоторым причинам, и учетная запись доступна с обоими номерами в течение года, и после этого будет использоваться только новый номер, как это должно обрабатываться способом DDD, мне было интересно, создаст ли он новый ограниченный контекст
DDD изменить совокупный корневой идентификатор
comment
Ограниченные контексты обычно имеют свой собственный универсальный язык, свой словарный запас. Для изменения количества цифр в идентификаторе вряд ли потребуется новый язык.
- person guillaume31 schedule 16.11.2017
Ответы (1)
Для объекта вы всегда хотите иметь технический идентификатор, то есть свойство Id (UUID), которое является неизменным и которое контролируется вашим приложением. Естественный идентификатор AccountNumber - это только объект-значение. По сути, в вашем приложении по техническим причинам используйте только Id, AccountNumber - это просто еще одна VO / деталь агрегата.
Изменение формата номера счета не должно создавать новый ограниченный контекст, это просто изменение внутри объекта значения. Но все проблемы, которые у вас возникают из-за изменения, проистекают из реализации, а не из моделирования предметной области (если только это не неправильная модель: D). Если вы используете Event Sourcing и CQRS, все должно быть относительно просто. Если вы используете ORM, который восстанавливает состояние, все будет сложнее.
Метод DDD означает, что вы должны понимать природу концепций, реальная реализация зависит от многих вещей.
person
MikeSW
schedule
15.11.2017
Каким образом использование источников событий упрощает задачу по сравнению с текущим постоянным состоянием?
- person plalx; 16.11.2017
