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

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

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

ммм.... ну вот пример на котором я своим пытаюсь это объяснять.

Есть у тебя функция которая принимает на вход массив объектов и должна по хитрой формуле посчитать скоры и отсортировать список по ним. Чистая функция. Без зависимостей.

Для изоляции тест кейсов нам надо:

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

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

нуууууууу... вообще звучит бредово. Но...

что бы у тебя был "агрегат уникальности email-ов" то есть некий объект который предоставляет гарантии что email всегда уникален - тебе надо что бы этот объект знал обо всех других email-ах. То есть когда чел регается - первая логическая транзакция это достать агрегат со всеми email-ами юзеров, попросить его "зарезервировать" твой, если это удается - идем дальше. Юзеров создаем и т.д. Соответсвенно если "дальше" падаем то надо откатывать резервацию email-а.

Вот так это "может" работать. Стоит ли так делать - скорее всего нет. В целом "уникальность email-а" это оч редко true invariant

менеджер должен решать какие задачи мне сейчас делать. Написание тестов это задача. Соответсвено менеджер и говорит, когда мне делать эту задачу (тождественно "когда мне писать тесты")

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

Звучит это как "если мне менеджер не сказал проверить что я сделал значит мне не надо проверять, QA потом потестят"

Почему? У этого агрегата айдишник является емейлом. И нам сам агрегат гарантирует уникальность в таком случае.

агрегат может гарантировать что-то только для того стэйта, который входит в агрегат. В этом случае тебе надо что бы был один агрегат на ВСЕ email-ы

Сов.верно, на проекте главная цель программиста - чтобы система работала только в его присутствии (лучше удалённом) 😀

нет времени - тесты не пишутся

Можем ли мы создать два агрегата с одинаковыми айдишниками?
У нас же инфраструктура гарантирует что нет.

можем.

это если ты в базе uniq constraint повесил

ну это уже зависит от разработчика и формы труда. Если оплата почасовая - то конечно я не буду писать тесты добровольно. А если окладная - то менеджер не выдал задачи - буду делать что-то сам

а потом люди пишут статьи о том что индустрия в плачевном состоянии

кто за это ответсвеный?

за качество? или за найм?

за "плачевное состояние"

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