Ads
Comments
Все это прекрасно работает до тех пор пока проект маленький и его просто поддерживать ввиду небольшого количества функционала. Интересно прочитать про то как удается придерживаться принципов SOLID в более приближенных к реальности условиях, типа дедлайнов, большого количества разрабов, работающих над одним проектом, нехватки квалифицированных кадров и отсутствия достаточного времени на ревью.
Особенно, когда проект вырастает стремительно. Вот еще «вчера» ты сидел в уютном проекте в одиночестве и все понимал, а вот уже у тебя в нем 10 разработчиков и проект вырос в четыре раза за 6 месяцев. Столкнулся недавно с такой проблемой. До сих пор разгребаем и выстраиваем работу.

Так solid как раз и помогает большим проектам, тк если это не так, то разгребание и понимание кода, а также его тестирование, превращается в боль

Про создание (D)TO- все надо делать обдуманно, не надо общих правил
https://stackoverflow.com/questions/21554977/should-services-always-return-dtos-or-can-they-also-return-domain-models


When not to Use


  • Small to mid size project (5 members max)
  • Project lifetime is 2 years or so.
  • No separate team for GUI, backend, etc.

Arguments Against DTO


Очень забавно читать про непринятие DI в контексте java разработки :)

Only those users with full accounts are able to leave comments. Log in, please.