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

Вообще есть несколько популярных подходов:

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

Они хороши тем, что при их использовании не надо думать. Просто берешь то, что хочется - и дело с концом 😃 Ну а если есть нужда или желание подойти к вопросу более серьезно - прошу под кат, будем разбираться.

В мире разработки существует множество архитектурных паттернов. Часть из них мы используем каждый день, часть - реже. Наверняка каждый из вас много раз видел синглтон и фабрику. Многие их писали. А вот когда я впервые прочёл про паттерн Строитель, то не понял поначалу, в какой ситуации его можно применить. Что совсем смешно: я регулярно использовал его реализацию (QueryBuilder из фреймворка Yii), но глаз настолько замылился, что я не смог сопоставить название и функционал этого класса с соответствующим паттерном проектирования 😂 Конечно, через некоторое время до меня дошло. А еще через некоторое - нашлась ситуация, в которую паттерн Строитель вписался идеально.

Вопрос о зоне ответственности того или иного класса в вопросах архитектуры не менее важен, чем ее стратегическое планирование. Сегодня я расскажу о том, как облегчить себе эту работу. Мы с вами решим довольно большое количество вопросов, из бесконечного многообразия классов оставив всего 2 их типа: ДТО и Сервис. Эти типы классов покрывают 90-99% всего необходимого в любом проекте. Итак, разберём, что они из себя представляют, и чем же так хорошо оставить только их.