Action-Domain-Responder — доработка MVC под задачи веба

[Fesor]

Вероятно, его можно было бы назвать Моделью, но это лишь внесло бы дополнительную путаницу.

Почему же? Модель предметной области. Никакой путаницы.

поместив логику для разных HTTP-методов в одно и то же Действие.

И это не есть хорошо, так как разные HTTP методы описывают разные действия. Ну во всяком случае обычно так происходит. Скажем в том же «Applying UML and patterns» контроллеры так же рекомендовалось делить по юзкейсам, с этой точки зрения все остается так же, так как контроллеры у вас всеравно по идее остаются, а действия стоит выносить в application layer сервисы, которые руководят общим флоу и реализуют уже юзкейсы. Правда частенько это избыточно.

Нэйт Эйбель возражает, что ADR следует считать заменой MVC

Ну да, MVC чисто UI-ная архитектура, и никакого отношения к бэкэнду иметь оно не может. Это кое как работало во времена когда сервер плевался статикой до всяких там ajax-ов и то по случайности.

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

[JustRoo]

Почему же? Модель предметной области. Никакой путаницы.

Полагаю, всё из-за тех же внутренних взаимодействий: модель «общается» с представлением, а домен — нет.

И это не есть хорошо, так как разные HTTP методы описывают разные действия. Ну во всяком случае обычно так происходит.

Именно. Но в MVC они все группируются в одном контроллере, а тут за такое бьют по рукам.

Вообще есть же гексагональная (луковая) архитектура

Которая из них?

[Fesor]

модель «общается» с представлением, а домен — нет.

В зависимости от сложности проекта. В идеале модель ничего не знает о внешнем мире и общается с ним только через DTO (на выход и на выход), а представление уже из этого DTO формируется. Это в большинстве случаев избыточно, потому такие мысли и появляются.

Именно. Но в MVC они все группируются в одном контроллере, а тут за такое бьют по рукам.

Не знаю как там в MVC, но в «Applying UML And patterns» рекомендовалось дробить контроллеры по юзкейсам, один контроллер на юзкейс.

Которая из них?

Трактовок хоть и много, но смысл почти все они передают один и тот же. Разница в количестве слоев, трактовках и т.д.

картинка

Скажем тут выделяют Framework Layer и он строго внизу иерархии (или в начале, как посмотреть), кто-то именует этот слой Infrastructure layer, кто-то этот слой делает сквозным, остальные слои завязаны на интерфейсы, а в слое инфраструктуры уже конкретно реализация.

Далее кто-то выделяет Domain и Core Domain, кто-то, а это большинство, не видят в таком разделении смысла и просто выделяют Domain Layer… Но суть остается одна — ограничение отвественности и все такое. Application layer и Domain Layer не зависят от фреймворков и прочей чуши, они завязаны на свои интерфейсы, а уже Framework/Infrastructure layer их реализуют. Ну и да, общение между между внешними и внутренними слоями должно происходит исключительно при помощи DTO. Но опять же многие считают это избыточным.

В большинстве случаев это все избыточно, и какие-то вещи склеиваются, какие-то упрощаются и т.д.

А еще есть CQRS, он пожалуй еще менее абстрактно описан.

[Fesor]

Ну да, по сути вот на этой картинке — Framework Layer это совокупность V и C, это тот слой где формируется нужное представление для каждого компонента (взаимодействие с базой, по HTTP или еще как) а так же контроллеры этих компонентов. А далее уже внутрь идет именно модель. Если сравнивать с ADR — то тут у нас application layer это A, D внутри а R где-то внутри Framework layer. И опять же action-ы работают с DTO а не с HttpRequest. Это будет такие вот application layer сервисы.

В зависимости от потребностей можно какие-то слои объединяться, склеивать, они могут чуть чуть перетекать друг в дружку…

[JustRoo]

То есть по факту ADR вполне себе нормально ложится на гексагональную структуру:

• Домен остается Доменом (разделение на Core и обычный сейчас не затрагиваем)
• Действия остаются в Application Layer
• Ответчики остаются в Framework/Infrastructure layer
• Добавляется Фронт-Контроллер, «оборачивающий» все HTTP-запросы в DTO (я же правильно понимаю, что это почти то же самое, что и Presentation Model?)
• Действия получают от Доменов точно такие же Presentation Model/DTO и передают их Ответчикам

[Fesor]

Ну как бы да. Единственное что:

— Presentation Model не есть DTO, DTO это довольно тупой объект-структурка, который просто переносит данные из одного слоя в другой (у меня скажем для этого используются обычные массивчики и stdObject, я делаю классы только для отдельных сложных случаев). Далее потом отдельные штуки уже из этих данных формируют представление и т.д.
— Фронт контроллер так же часть framework/infrastructure layer. Вообще все контроллеры туда ложатся
— контроллеры там все равно есть, помимо экшенов. Они готовят DTO и дергают экшены. Опять же я к примеру далеко не всегда делаю отдельные сервисы-экшены так как обычно это оверхэд.

[skiedr]

Еще когда оригинал читал, заметил, что DCI ни к MVC ни к ADR никаким боком не подходит. DCI применим внутри доменной логики, это не общеархитектурный паттерн. Я бы DCI скорее с монадическими вычислениями ассоциировал.