Как правильно построить архитектуру?

Question

[DorAndor]

Приветствую.
Работал со всякими самописными системами, где главное было сделать задачу. Поэтому накопилось много глупых вопросов по правильной архитектуре, т.к. зачастую вся логика была в контроллере или в моделе. Стал смотреть на Laravel.
По архитектуре есть несколько явно легких вопросов:

1. На примере laravel увидел, что логика выносится в сервисы (или в экшены, если это одно действие), например. Тут хотел бы понять на небольшом примере как организовать сервис или даже несколько. Хочется построить отчет по расчету зарплаты сотрудника, который обрабатывает заказы и делает различные действия. Создал сервис ReportService. Внутри есть много различных методов, каждый считает определенные действия сотрудника и это суммируется в его зарплату (например: подсчет обработанных заказов, подсчет звонков, подсчет отправленных посылок и т.д.). Правильно ли это делать в одном сервисе или надо как-то иначе, разбить все на разные классы?
   Если говорить о Laravel, то как правильно в этом сервисе обращаться к другим классам? Передавать их из контроллера или делать их видимыми везде?
   
2. Еще один странный вопрос. При создании всяких отчетов всегда появляется множество переменных, в которых что-либо хранится при расчетах. Есть ли какой-то правильный красивый подход, чтобы их создавать и т.д.? Чтобы не было типа такого (не в плане имени переменной, а такой вот странной простыни):
   $param1 = 0;
   $param2 = 0;
   $param3 = 0;
   $param4 = 0;
   
   

Спасибо, если кто ответит на такие странные вопросы, а может и примерами кода )

Comments

[Дмитрий]

На примере laravel увидел, что логика выносится в сервисы (или в экшены, если это одно действие), например

thin controller fat service/model

Правильно ли это делать в одном сервисе или надо как-то иначе, разбить все на разные классы?

Буква S из словосочетания SOLID.

Если говорить о Laravel, то как правильно в этом сервисе обращаться к другим классам? Передавать их из контроллера или делать их видимыми везде?

dependency injection in laravel

При создании всяких отчетов всегда появляется множество переменных, в которых что-либо хранится при расчетах

dto pattern laravel

З.Ы. DDD

Answer 1

[Sanes]

Делайте, как вам удобно. Что-то куда-то выносить имеет смысл, если будете переиспользовать или не хотите видеть огромную портянку в коде.
Простейший CRUD прекрасно живет в одном контроллере. Если много связей, то имеет смысл вынести их в Трейты.
Отчеты, подсчёты и т.п. обычно делаются в фоновом режиме. Для этого в laravel придумали очереди и планировщик.

Comments

[DorAndor]

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

[Sanes]

DorAndor, со временем решите для себя. Зависит от конкретного проекта. Фреймворки уже выстроены более или менее нормально. Я например рассматриваю Laravel, как инструмент для несложных MVP проектов. Для меня этого достаточно.

Answer 2

[Saboteur]

Архитектура строится исходя из
1. как это будет запускаться, на каких ресурсах, хватит ли 1-2 cpu сейчас или через год, если надо будет масштабировать?

2. Опять же сколько данных будет через год или 5 лет, будут ли они обрабатываться также быстро?

3. Надо будет обновлять софт - ОС, версию java или еще чего. Насколько удобно и легко это будет делать

4. Нужно ли вам работа 24/7, или можно отключать систему по ночам или выходным для различных технических требований (апгрейды, бэкапы, миграции)

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

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

Answer 3

[dmitriy]

1. Создал сервис ReportService. - правильное направление, но могут возникнуть проблемы когда ReportService использует UserService а UserService использует ReportService. Тут необходимо разделение сервисов на уровня приложения Aplication Services и доменных Domain Services, первые могут использовать domain services, вторые не должны использовать aplication services. Есть еще вариант организации бизнес логики через Command и Handlers.
2. DTO