ПГ
строишь приложение с подходом "приложение = чистая функция"? 🙂
Мне кажется так тестироватьпроще будет. В так выходит юзкейс с 10 зависомотями, и все надо мокать
Size: a a a
2020 October 05
VS
у меня сущность "услуга"
У нее свои мелкие свойства, а потом пошли связи: владелец, тип(категория), город, соц сети, ссылки на ютуб, галерея фото. Коллекции хранятся в "услуге". Я бы срадостью вынес коллекции но не понимаю, как тогда работать с коллекцией вне агрегата, так как есть всякие штуки типа "нельзя 2 ссылки на одну соц сеть", "должна быть минимум одна картинка". Можно вынести в какой нить сервис класс - но тогда надо плотно работать с репозиторием будет и не потестировать без него.
У нее свои мелкие свойства, а потом пошли связи: владелец, тип(категория), город, соц сети, ссылки на ютуб, галерея фото. Коллекции хранятся в "услуге". Я бы срадостью вынес коллекции но не понимаю, как тогда работать с коллекцией вне агрегата, так как есть всякие штуки типа "нельзя 2 ссылки на одну соц сеть", "должна быть минимум одна картинка". Можно вынести в какой нить сервис класс - но тогда надо плотно работать с репозиторием будет и не потестировать без него.
Ну это стандартная дичь. У меня так же)
Агрегат - про транзакцию(юз кейс).
Как связано это всё в юз кейс? Догадываюсь, что через ui.
Агрегат - про транзакцию(юз кейс).
Как связано это всё в юз кейс? Догадываюсь, что через ui.
DT
то что ты загружаешь все данные для агрегата из репов - ты восстанавливаешь его состояние, и ничего более
DT
ты можешь с таким же успехом его держать в памяти бесконечно, и тебе не придется с репами вообще возиться
DT
только это никак не связанно с самим агрегатом и данными, с которыми он работает
ПГ
то что ты загружаешь все данные для агрегата из репов - ты восстанавливаешь его состояние, и ничего более
Ну я к чему: у меня например сейчас $agr->addSocial(string $link), а это будет какой то сервис $socialService->addSocial(srtring $link)
VS
у меня сущность "услуга"
У нее свои мелкие свойства, а потом пошли связи: владелец, тип(категория), город, соц сети, ссылки на ютуб, галерея фото. Коллекции хранятся в "услуге". Я бы срадостью вынес коллекции но не понимаю, как тогда работать с коллекцией вне агрегата, так как есть всякие штуки типа "нельзя 2 ссылки на одну соц сеть", "должна быть минимум одна картинка". Можно вынести в какой нить сервис класс - но тогда надо плотно работать с репозиторием будет и не потестировать без него.
У нее свои мелкие свойства, а потом пошли связи: владелец, тип(категория), город, соц сети, ссылки на ютуб, галерея фото. Коллекции хранятся в "услуге". Я бы срадостью вынес коллекции но не понимаю, как тогда работать с коллекцией вне агрегата, так как есть всякие штуки типа "нельзя 2 ссылки на одну соц сеть", "должна быть минимум одна картинка". Можно вынести в какой нить сервис класс - но тогда надо плотно работать с репозиторием будет и не потестировать без него.
С таким подходом можно пол базы засунуть в агрегат.
DT
ты перепридумываешь CRUD?
ПГ
ты перепридумываешь CRUD?
Да)
DT
зачем круд тестировать?
ПГ
зачем круд тестировать?
Ну тут скорее обратная логика: если тесты пишутся хорошо, значит код норм, если нет - значит и код плохой. Я смотрю как будут тесты выглядеть.
DT
Ну тут скорее обратная логика: если тесты пишутся хорошо, значит код норм, если нет - значит и код плохой. Я смотрю как будут тесты выглядеть.
нет, тут прямая логика. Не надо тестировать то, что не надо тестировать. И проблема сложности написания тестов решается сама собой