я себя не могу экспертом в тестировании назвать.
Но тесты такого ядра
1) Выполняются моментально
2) Не требуют фикстур
А следовательно работать с ними комфортнее и быстрее.

но остается слабое место, мы делаем допущение, что репозитории (и другие инфраструктурные сервисы скрытые за адаптерами) выдают корректные данные.  Я пока не надумал как с этим быть и нужно ли что то придумывать. Репозитории никак не тестируются сейчас.

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

Ну тоесть из второго пункта какие-то влажные мечты о "реюзе" кода между проектами. Для домена. Ага.

А потом оказывается что у тебя юзера какие часть домена. И прочие второстепенные вещи. Ибо кор домен в обстоятельство "там доктрина а там нет" вряд-ли попадет

И да и нет. Да в плане что тот домен который удобно тестировать "отделен" от хранилища. Нет потому что там где логика не должно быть зависимостей, недостаточно изолировать только от хранилища

Гугли beyond solid: dependency elimination principle. Может натолкнет на идеи интересные

Вот второй пункт интересно. А почему фикстуры нужны? А ты в тестах прекондишен не выставляешь?

Должны быть приемочные тесты. Логики как правило в персистенс нет так что достаточно удобно

Подскажите пожалуйста как поступить в такой ситуации: нужно дать пользователю возможность редактировать свой профиль без указания нового пароля (но в форме есть элемент пароль).
- Есть форма UserType c элементом password с типом RepeatedType и data_class = User::class,.
- Есть сущность User, в ней есть поле $password c Constraints\NotBlank и на getPassword и setPassword установлено жесткий тип string.
- в контроллере $form->get('password')->setRequired(false);, сабмичу форму без пароля и тут начинаются нюансы при вызове $form->handleRequest($request); (как я понимаю что форма пытается данные $request натянуть на сущность User и не получается потому, что в сущности указан жесткий тип string, а передаю я null)

Насколько правильно указать getPassword и setPassword тип null|string и в контроллере проверять если не указан пароль, то указывать через setPassword текузий пароль юзера из бд? в этом решении меня смущает, что я пароль могу указать в null

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

👍

Тут такая тактика беседы у всех) если явно не сказал, значит у тебя там говно😂

Вот продолжая про "накладывание слоёв на структуру проекта". Когда нужно написать какой-то оптимизированный код, то эти абстракции начинают сильно мешать. Весь модуль написан в одном стиле, а тебе надо как-то туда вклиниться и нарушить все, что можно. Да даже не понятно бывает, куда такой код положить, ибо там все может быть вперемешку, и домен, и инфраструктура. Вот тогда, конечно, начинаешь сомневаться, а верным путём ли мы пошли, товарищи :)

Вообще все это не про symfony, конечно. Может, чатик по архитектуре есть какой :)

Реюз как слои. Оверсимплифаед версия сложной концепции, в данном случае модулярности

От других частей домена тоже ;)

Да.

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

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

Нужно экономить это вот "мыслетопливо" про которое Дорофеев вещает

а это как? В смысле скопировал и поменял - такой реюз чтоли?)