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

Да.
Понимаю, что термины в разных контекстах могут означать разные вещи. Сейчас  пытаюсь выстроить флоу.

вот в этой bunded context canvas есть интересный концепт Model/Trait - вот я б внимательно с этим ознакомился. Мне например когда я с этим знакомился далеко не сразу понял для чего это. Особенно draft/execute/audit но это может помочь с поиском частей процессов.

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

не знаю насколько корректно это сравнивать с activity в value stream (не компетентен) но оч похоже выглядит

Спасибо.
Пока что не все понимаю, но очень интересно :)

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

https://youtu.be/mMo8G3gCOtA?t=1657
Как думаете, он прав совмещая инварианты и валидацию? Раньше он этого не делал, как и я собственно.
Мне кажется он всё же свернул куда-то не туда добавив монаду Result в домен как фабричный метод.

валидация тут это проверка прекондишенов операции. Есть прекондишены которые относятся к домену а есть прекондишены которые не обязательно должны быть в домене. Как понять - что будет если правило нарушено - последствия. никаких? ну можно на уровне UI оставить

в случае @ - что мол "у человека должен быть валидный email - в целом тут последствие может быть "мы не сможем отправить email" и это может быть важно для логики. А потому мы наверное хотим это форсить

проблема в том что ты не можешь это определить только по сабачке - ты только понижаешь вероятность что это валидный email.

опять же - валидация это логика. логика валидации может быть чистой функцией. валидация обычно достаточно атомарна и хорошо ложится в домен. Ну и главное - rule of thumb - в application layer стоит избегать логики. Там только склейка операций, сценарии

но вообще прикольно, надо глянуть видос внимательнее

о, вот он рассказывает про различия прекондишенов которые технические ограничения и бизнесовые вроде...

короч пока вроде не заметил что бы он чет стремное рекомендовал - посмотрю еще раз но пока вроде согласен (хотя часто так не делаю потому что я ленивая жопа)

На моей практике обычно было так:
- фабричный метод всегда в отдельной фабрике(конструктор классов в домене публичный, перегруженный)
- валидатор/парсер отдельно
- в доменных классах бросаем эксепшны если инварианты(без @ и вот этого всего) нарушены

И объяснение этому было достаточно простое: на самом деле нам не нужно знать в домене как происходила валидация, да у нас нет 100% гарантий на то что Email был провалидирован при создании, но мы ожидаем что он валиден (у него например есть поля вроде новый / был верифицирован) если что-то на него отправляем то мы будем смотреть эти более высокоуровневые поля никогда не используя информацию о том есть ли в нем @.

причем у нас есть инварианты при переходе в которые нам не нужен парсинг завово(почти все, не помню чтобы это было нужно когда-либо)

Если есть vo значит оно валидно. Фабрика в этом случае это гарантирует. Правила что считать валидным как правило в домене

Ну вот я к тому что проверки вроде @ - чаще всего абсолютно не важны для кода в домене, потому что там мы уже абстрагировались от них на более высокий уровень.

не солидно как-то