Я вообще придумал эту ситуацию. Я пока разбираюсь с DDD. Интересно решение именно в контексте того, что старые данные нужно оставить.

Могу конкретизировать. Есть агрегат клиента. Раньше бизнес считал, что у клиента может быть 10 контакных номеров телефона. Потом решили, что не больше 2, а старым клиентам просто не давать добавлять новые

Как вариант. Но интересно решение для случая когда старые данных нужно сохранить

Ну то есть ориентироваться на ID или дату это нормальный вариант в случае если бизнес решает оставить старые данные?

Ну возможно тогда сделать правила валидации отдельным классом и подсовывать нужный в зависимости от условий, на которые вы завяжетесь. Вчера 10 номеров, сегодня 2, завтра 100 - без разницы.

Два агрегата, условные NewClient и OldClient вполне валидный вариант. Как вы будете определять, по ID, дате и т.д. не столь важно. Но не имеет смысла обсуждать DDD без бизнеса. Это не про код, не про БД, миграции, сущности и объекты-значения. Это про бизнес и  взаимодействие с ним. Все концепции вроде агрегатов, сущностей и т.д. придуманы только как общепринитыя идеи выражения бизнес правил.

вообще ДДД тебя должно учить с бизнесом такое обсуждать) это ж не техническая проблема в целом

шо обсудим multi cloud disaster recovery?

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

мне кажется, что тогда отдаляешься от причин, по которым ты делаешь изменения. Это будет влиять на качество кода.
Хотя если системный аналитик код пишет - тогда такой проблемы не будет, наверное 🤔
Ну или там системному аналитику всё равно придётся объяснить что зачем и почему. Если так, то непонятно зачем ещё одна прослойка 🤔

Надо начать с того что системный аналитик это роль которая вообще не в каждой команде есть
А ддд это про всех

ну... смотря как у тебя процесс построен. если у тебя такой умный системный аналитик рисует картинки а потом обезьянки разработчики по картинкам делают не то...

тут же вопрос масштаба. на каком-то большом масштабе энтерпрайза у тебя могут сидеть системные аналитики и там контексты нарезать. Но моделирование процессов внутри контекста дело уже отдельных команд и там domain story telling, process mapping, etc - тут уже все задействованы

ХЗ правда как там они нарежут у себя "наверху". Хотя если это чисто роль и эту роль исполняют программеры
В общем мне кажется, что системный аналитик - это роль кого-то из программистов. Ну или системные аналитики тоже код пишут, а не какие-то отдельные "анализирующие" люди

а может они и сами про эти все декомпозиции знают и их там этому учат? 🤔

Тогда надо сначала в системные аналитики, а потом уже там код всякий учиться писать
нипаняяятна

Понял. Спасибо

А еще вопрос. Инварианты агрегата должны проверяться каждый раз при создании агрегата?

Вот пример:

Есть агрегат Post. У него есть параметры slug и title.
Инвариант: slug = translited(title).

Агрегат сохранен в бд вместе со slug и title.

Теперь получается, что при каждой инициализации агрегата в репозитории мне нужно проверять инвариант slug = translited(title), несмотря на то, что он уже получаен и есть в бд?

В таком случае, наверное, лучше не делать такой инвариант у агрегата и вынести создание slug в доменный сервис?

инвариант ли это. вот в чем вопрос. есть еще прекондишены

что значит "инициализации в репозитории"? мне кажется что-то не то. У агрегата только одна точка "начала жизни". просто убери логику из конструктора или создавай свои агрегаты рефлексией без вызова оного