Ну, сделали не все, что хотели, но многое. остальное еще обдумывать и обдумывать и будут сделано в tndt-84, tndt-85 и tndt-88

ViewModel, которую мы очень хотели мы добавили. Далее надо бы сделать её действительно универсальной, чтобы task тоже мог ей пользоваться, и завести для смены статуса документа csrf. Но последнее вылезает за эту задачу. Может выделить в отдельную?

Думается разделение евентов мы отложим до появления презентационных евентов. Вновс security в services до разеления services на презентационные, application и доменные

Давайте сейчас просто разделим директивы включения директорий в места, где контейнер ищет сервисы. А разносить их по разным файлам будем позже, когда по разным слоям разделим директорию src/Service

src/Service/CommentService, это сервис домена (так как определяет логику), application (так как разбирается с тем как его добавлять, или presentation, так как работает с формами?

Сейчас нам пора вносить Security в Service, а по конфигам они разделены, что делать? Подключать директкорию Services по папам?

• presentation.yml -> src/controller, src/Services/Twig
• event.yml -> src/EventSubscriber
• infrastructure.yml -> src/Repository, src/Service/Doctrine
• domain.yml -> src/Service/…

А что делать с сервисами в корне Service? Сделать из их домен?

Если разбивать файлы по директориям, мы столкнемся с крайне неравномерным заполнением файлов. Подавляющее большинство сервисов, как ни удивительно лежи в директории Services, по итогу у нас будут почти пустые eventSubscriber.yml, и огромный services.yml А многие сервисы, которым место в presentations.yml все равно будут лежать в services, например Twig, потому что сами эти сервисы лежат в src/Service. Либо уж, раз мы перераспределяем описания, то надо сразу же и слои разелять, на Infrastructure/{Repository, Service/DoctrineType}, Presentation/{Controller, Transformer, Service/Twig}, etc.

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

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

• services.yml - здесь включаем автовайринг в src/Services и описываем необычные сервисы
• eventSubscriber - здесь включаем автоваринг для обработчиков событий, и описаем требующие особых тегов
• AjaxTransformer - включаем для трансформеров (тут правда, скорее всего ничего описывать не нужно будет. Но может тут смоем сконфигурировать сериализер, так чтобы им легко пользоваться.

Альтернатива последнему

• presentation - Здесь будут и контроллеры и трансформеры и прочее. В будущем tndt-85 сюда уйдут из сервисов Twig-хелперы

Ну что, пока бодренько

но может быть не этой задачей

И да, включаем ли мы Entity в Model? по идее да, включаем

и так, мы сходу наталкиваемся на вопрос.

• Model
  • Project
    • Enum
    • Dto
  • Task
    • Enum
    • Dto
  • Doc

Или

• Model
  • Enum
    • Activity
    • Doc
  • Dto
    • Project
    • Doc

Так как здесь мы не только сервисы перемещаем, но и разбираем Dictionary включая перенос моделей, стоит здесь же сделать ViewTransformer и ViewModel. И создать модель для кнопки, чтобы контроллер не забывал заполнять её поля.

Похоже наши корневые сервисы виде TaskService, CommentService надо разделять на два слоя:

• слой необходимого для совершения действия. Заполнение и сохранение сущности, проверка непротиворечивости инфы и дополнение, вроде установка isClosed при установке этапа завершающего задачу.
• слой бизнес-сценариев тех или иных действий. Вызывает предыдущий слой, но попутно выбрасывает евенты, меняют другие связанные сущности и т.д.

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

Да, еще с введением слоя доменных сервисов, стал избыточен слой Filler’ов, которым мы так гордились. Это явно слой домена, просто он зависеть должен не от dto, а от контракта на dto

очень хочется завернуть assets и templates ближе друг к другу, сейчас они в разных концах, но во-первых они не в src, во-вторых это уже предполагает разделение на гексагональные слои, оставляем это на tndt-85

Перенес из комента план в тз и сменил тип на рефакторинг, потому что с тем, что куда перекладываем мы в целом определились.

Куда девать Contract? С одной стороны там совершенно разные контракты, в том числе и для form/DTO что сейчас не очевидно, так что то же в корень.

С другой он уже был в корне, и мы решили его класть поддерктторией туда где нужно, но не факт ,что это было верное решение

и так до разделения на гексагональную архитектуру уже сейчас стоит.

• src/Model и в неё все объекты:
  • Entity базы данных
  • Enum и в неё все enum’ы
  • DTO вроде Project/TaskSettings
  • VO когда будут
  • в неё не идут объекты, которые в будущем пойдут в presentation (их либо пока оставляем в Form/DTO, либо делаем новую папку src/ViewModel
• src/Services и в неё все сервисы
  • Service/Security
  • Service/Dictionary - и сюда Fetcher, Stylizer который потом все равно исчезнет отдав работу в Service/Table/TaskTableStylizer или ViewModel/Table/TaskTable, TaskTableItem
• доменные сервисы в размышлении либо
  • src/Domain - как начало нового слоя
  • src/Services/Domain чтобы не путать с сервисами непойми куда, вроде BadgeService или CommentService

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

Хотя бы частично мы это решим в tndt-85, по мере разноса всего на слои

Деление сущностей по принципу могут или не могут они храниться в бд, отображаться в форме и т.д. нелогично. Сегодня ProjectSettings лежит в Entity/Project, а завтра мы переложим его в монгу? Сегодня TaskTableQuery лежит как объект формы фильтров списка задач, а завтра начнет храниться в базе, тоже перекладывать? Так он не прекратит быть частью формы.

И так, думается мы возвращаемся к глобальной директории Model, но только после разделения на слои и в пределах слоя.

• Application/Model/Entity
• Application/Model/Jlob??
• Presentation/ViewModel/Form
• Presentation/ViewModel/Task?

Внутреннее дееление этой директории еще стоит продумать

Кстати это нас возвращает к мысли, что раз словари жестко привязаны к Entity/Project, может и их тоже стоило хранить в Entity, как объекты лежащие в базе? глупость скорее всего, ну лежат и лежат, а потом у нас будут объекты, которые могут быть в базе, а могут и нет

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

И Object/JlobObjectInterface, который можно или убрать в Entity/Contract (но пользуется им объекты не только лежащие в Entity, но и словари. Либо в отдельную папку src/Contract но целая папка ради одного интерфейса, при том, что куча интерфейсов у нас по месту, такое себе.

А если мы уж напишем сложную реалиацю кеша, стоит сервис разделить, на Fetcher и между ним и миром прокси в виде Regisry

Честно говоря к DictionaryService Registry то же не очень клеится. То, что он умеет кешировать в себе словари (сейчас нет, только проекты), внутренняя реализация, и знать об этом внешнему коду не обязательно. Может DictionaryFetcher или DictionaryGetter?

Repository vs Registry

• Repository место хранения непосредствено объекта (почти всегда база, хотя может быть например redis, если это самостоятельный объект, не кеш).
• Regisry хранит кешированную ссылку не него (умеет по аргументу извлечь из другого места, например правильно распаковать из аргумента), или берет из репозитория и кеширует у себя.

Формы и Репозитории работают по всему проекту, как Controller и Command, в них лежат классы для разных сущностей и подсистем. С появлением ajax у нас будет StatisticController, SearchController, CommentController. В формах у нас же есть контролы для справочников ,оторванные от сущностей. А вот Dictionary, как и Service сам в себе

Чтобы у нас на первом уровне не развелись десятки директорий, можно небольшие изолированные сервисы убрать в Services

• Service/Dictionary
• Service/Setting
• Service/Statistic Правда чем они отличаются от Security, может и его в Service? А Form, Repository?

Entity лежат в одном месте, потом что реализуют одну и ту же логику, хранение в БД, и подчиняются единой логике, у них нет зависимостей, под ними в кеше лежат прокси классы. Object’ы неоднородны, кто-то будет лежать в полях entity, кто-то в других объектах. Кто-то должен наследовать справочники, кто-то просто должен сериализоваться. Кто-то вобще окажется в сессии или в кеше.

Так что стоит наверно выделить директорию Dictionary аналогично Security. А в ней уже и объекты, и сервисы, как в Forms их DTO и контролы. Settings будет отдельно, хотя не ясно где.