Кажется у нас потихоньку выкристализовывается инфраструктура.

• Presentation
  • Controller
  • ViewModel
• Domain
  • TaskService
  • DocService
• Infrastructure
  • Doctrine
  • RequestResolver
  • Monolog
• Application
  • все остальные сервисы
  • Statistics
  • Badges
  • Wiki

• src
  • web
    • Controller
    • Service
    • ViewModel
  • App
    • Event
    • Service

Чтобы не плодить полупустых слоев с километровыми названиями в namespace, можно сокращать названия, а те, в которых только одно деление не указывать

• src
  • web
    • Controller
    • Service
    • ViewModel
  • App
    • Event
    • Service

вобще говоря можно выделить слой не создавая новый уровень деления, т.е.

• src
  • Presentation
    • Conroller
    • Service
    • ViewModel
  • Service
  • Event

Не очень красиво, но решает нашу проблему целого уровня состоящего из двух папок, но удлиняющего FQCN каждого класса

Когда мы здесь разнесем src/Services по разным слоям, так же надо будет разнести и config/<env>/services/0-ommon.yml по разным файлам

У нас в enum порой встречаются чисто презентационные вещи, вроде кодов переводов всплывающих сообщений. Их по хорошему надо выделить в отдельные enum, но как из них получать что-то по базовому enum (тем более, что сами enum не наследуются).

Разве что FlashMessages::docState($doc->getState()), но это наверное дело отдельной задачи, когда мы разделим слои и будем натыкать на разный код не из того слоя.

Директории Viewmodel и ViewTransformer сделаем в tndt-42

Кстати можно уже сейчас завести директории

• src/Viewmodel/Task/ControlButton
• src/ViewTransformer/Ajax/Activity etc

так-то красиво, и все сдвинуты вниз, но если с viewModel вопросов особо нет, потом туда приедет Task, TaskInTable и т.д., но будет ли директория ViewTransformer/Html, там же все решается твиг? Впрочем, а где будет лежать TaskTransformer::toTableItem(Entity/Task $entity): ViewModel/Task?

Кстати потом будет проще их на vue переделывать, если мы этого захотим

Когда будем разделять, можно сразу завести презентационные dto например для контролов

class ControlButton {
  private $action;
  private $label;
  private $needConfirm;
  private $confirmText;
}

и тому подобное.

Все еще актуально, но мы все еще не уверены, что уже пора, и не уверены насчет некоторых объектов. Оставляем на потом , когда накопится понимание. Пока продолжаем исследовать

Я до сих пор не уверен, что время деления на слои гексагональной архитектуры уже пришло. Как-то куцо будет выглядеть src с двумя папками Application и Presentation. С другой стороны когда файлов будет больше может быть больно их перемещать.

Но вот например презентация. Контроллеры перемещать src/Controller -> src/Presentation/Controller или src/Presentation/web/Controller (а когда появится coreUI - src/Presentation/web2/Controller)?

У нас есть класс сервисов, которые лежат просто в корне сервисов, но просятся в отдельную директорию, возможно даже вне сервисов, как зачаток нового большого слоя. Это Domain, т.е. сервисы непосредствено выполняющие бизнес-логику приложения

• Выносим их в src/Application/Service/Domain
• Выносим их в src/Application/Domain
• Выносим их в src/Domain, чтобы сразу) Так же им будут нужна своя директория Contracts с интрефейсами принимаемых ими объектов (Request)

Я думаю это решается так, мы, наконец делаем фильтрацию списка задач. Смотрим насколько некрасиво он лежит, и принимаемся за эту

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

Что мы получим с этого разделения, и сколько времени потратим

Badges остаются в сервисах, отдают именно объекты, причем по типам, чтобы презентация могла их фильтровать, если на какой-то из страниц бадж не нужен или должен отображаться не стандартно. BadgesExtension в презентацию, и просмотреть его только ли он про отображение.

Отдельный здесь вопрос с контроллерами. Так как мы вводим слои по требованию, в них сейчас есть разная бизнес-логика. Да, они даже евенты порой посылают. Так что:

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

• Точно перенести если есть вызов бизнес-евента
• Filler тут подумать. Он зависит от типов данных в представлении, так что вероятно в презентацию. Но он имеет бизнес-правила работы с сущностями, впрочем большинство из них заданы нашими сущностями, являющиеся бизнес-моделями, так что ок. Их в презентацию, но их обязательно надо осмотреть на предмет бизнес-логики и по её наличию подумать как отделить филлер от бизнес-события add,edit. etc

Как сделать TaskSettings разрешенным типом атрибута смотри Enum в качестве атрибута сущности

У нас есть две задачи практически об одном и том же. Эта, tndt-85 и tndt-88. Только эта чуть более предметна, про Services, а та в общем по ddd (хотя скорее мы думсаем о гексагональной архитектуре, чем о ddd). Предлагаю эту перформулировать в выделение слоя Presentation и уносу всего остального в Application. А ту в исследование о том, выделять ли отдельные Infrastructure и Domain из Application

Да, так и сделаем

Так же здесь стоит подумать и переименовывать директории Object в Model И определиться, мы все FormType называем Type или те, что контролы называем Type, а те, что формы Form.

• С одной стороны это удобное разделение.
• С другой у Symfony есть еще и FormView, и хотелось бы не путать. Может просто контролы класть в отдельные директории, как сейчас есть директория Base