Ну я и хочу сделать нормально

то на боевом проекте увы это будет фиаско

https://pastebin.com/HVXrRUig

Ребят, нужна помощь по архитектуре: Я не могу разложить бекенд на модели, сервисы моделей и сервисы приложения (аля DDD) Вот есть контроллер. Он принимает запрос, парсит post, дальше он должен подергать сервисы приложения и вернуть ответ. Есть сервис. Он получает репозиторий, создает в себе конструктор ентити, и имеет публичный интерфейс для контроллера. Состояния он не имеет. Есль модель (в моем случае ентити Доктрины). Там лежат данные таблицы и функции изменения этих данных геттеры, сеттеры. Есть репозитории, как коллекции ентити-моделей, для выгрузки, удаления и загрузки групп данных Естественно, классы ентити эти - с кучей связей между собой (бд на 30+ сущностей). Примеры в интернете - это 3-4 сущности и там конечно слоев абстракции городить не надо. Вопрос: если наша ентити - это класс доктрины, в DDD это домейн модел или домейн сервис? (мне кажется что сервис)

Домейн модел это бизнес правила общие для всего приложения. Домейн сервайс это правила для каких то частей приложения. Вот и вся разница. Как реализовывать это другое дело. Кто-то пытается всю логику положить в ентити докрины, разбивает ентити на велью обжекты через ембедед классы. Но по моему проще всю логику делать в сервисах. Какие делать сервисы, с каким связями, в каком количестве, сколько слоев, это все зависит от задачи. В общем, нужно стараться высокоуровневую логику делать не зависящей от низкоуровневой. Чем ближе к вводу-выводу, тем ниже уровень.

Книжка дяди Боба в закладках, руки не дошли Мы в итоге решили так: Ентити - рулят своими полями и методами детей Репозитории - как коллекции чтения/записи Сервисы - Бизнес логика, сервис ентити имеет его тип, DI репозитория и других сервисов для работы Контроллеры - дергают методы сервисов, ничего не знают про ввод-вывод

> Сервисы - Бизнес логика, сервис ентити имеет его тип, DI репозитория и других сервисов для работы Вот это не понял

Ентити-Сервис знает как работать с привязанной к нему коллекцией ентити. Другие сервисы подключаются к нему через DI в конструкторе вместе с репозиторием. Есть независимые сервисы, которые просто реализуют бизнес логику, дергая другие сервисы

Ребят. Подскажите оптимальную стратегию определения, что поля, пришедшие с фронта несут изменения. На фронте форма 10+ полей. Юзер что то меняет в одном поле и сабмитит форму. В контроллер приходят все 10 полей. В какой момент лучше определять, что изменено одно поле? - Верить фронту и с фронта отправлять только измененные поля? - Сделать DTO с сеттерами, инициировать её начальными данными и в момент десериализации определять "новое !== текущее" и заполнять некий массив changed? - Сделать в Entity сеттеры, в которых проверяется "новое !== текущее" и заполнять некий массив changed? - Ловить изменения через события доктрины перед коммитом? иле еще как? В конечном счете мне нужно будет создать событие "изменено поле тое-то, было... стало..."

Ребят, если есть шарящие по курсам: лучше "Symfony casts" или "knpuniversity"? или что-то третее типа Udemy с англ норм