DollyPapper,
юзкейсы — это сценарии использования, что как-бы дословно и переводится
отличия от др сервисов в том, что др сервисы — какие-то службы с какой-то ответственностью, отличной от бизнесс-процесса
например нужно что-то сбилдить или трансформировать или даты обработать или еще что-то
а юзкесы: это сценарии по бизнесухе, например регистрация пользователя, удаление, блокировка
если посомтреть по Мартину, то у него как ра такие юзкейсы
просто слово "сервисы" очень обтекаемое и не говорит чего там происходит, бизнес-логика или просто вспомогательное что-то или фиг пойми что
если хотите прямо отделить, то доменный уровень будет знать только о интерфейсе
а вот реализация лежать не в домене
чтобы все же соблюсти эту чистоту и не сильно усложнить, то можно систему разбить на модули/фичи
и каждый модуль будет иметь такие слои
почему лучше это сделать:
- реализация репозиториев хоть и инфраструктурная, но правится часто при изменении домена, а значит сильно далеко прятать не вариант, иначе сильно все будет размазано... потому модуль делают трехслойным (инфра, домен и апликейшн слой)
P747, да, доктрина смотрит на код и на состояние БД
если есть новая сущность для маппинга и она видит, что в БД нет таблицы — создастся миграция с озданием таковой с нужными полями
P747,
если вы создатие руками таблицу то при синхронизации сущностей и БД ваша таблица будет лишней, и значит создастся миграция на удаление таковой (если не отметить, что ее надо игнорировать)
но пара фич имеет свои контроллеры (упоминал Security, тк высока вероятность править в контексте самого модуля и др части вместе с контроллерами) и еще парочка
Не снаружи же это контролировать
Ну типа стейт-машина на минималках и контроль со стороны сущности, тк данные в ней же (информационный эксперт и закон Деметры как-никак)
$myLogger,
$messageFormater