Комментарии 7
Вероятно, его можно было бы назвать Моделью, но это лишь внесло бы дополнительную путаницу.
Почему же? Модель предметной области. Никакой путаницы.
поместив логику для разных HTTP-методов в одно и то же Действие.
И это не есть хорошо, так как разные HTTP методы описывают разные действия. Ну во всяком случае обычно так происходит. Скажем в том же «Applying UML and patterns» контроллеры так же рекомендовалось делить по юзкейсам, с этой точки зрения все остается так же, так как контроллеры у вас всеравно по идее остаются, а действия стоит выносить в application layer сервисы, которые руководят общим флоу и реализуют уже юзкейсы. Правда частенько это избыточно.
Нэйт Эйбель возражает, что ADR следует считать заменой MVC
Ну да, MVC чисто UI-ная архитектура, и никакого отношения к бэкэнду иметь оно не может. Это кое как работало во времена когда сервер плевался статикой до всяких там ajax-ов и то по случайности.
Вообще есть же гексагональная (луковая) архитектура, которая менее абстрактна и более четко дает представление о том что где.
0
Почему же? Модель предметной области. Никакой путаницы.
Полагаю, всё из-за тех же внутренних взаимодействий: модель «общается» с представлением, а домен — нет.
И это не есть хорошо, так как разные HTTP методы описывают разные действия. Ну во всяком случае обычно так происходит.
Именно. Но в MVC они все группируются в одном контроллере, а тут за такое бьют по рукам.
Вообще есть же гексагональная (луковая) архитектура
Которая из них?
0
модель «общается» с представлением, а домен — нет.
В зависимости от сложности проекта. В идеале модель ничего не знает о внешнем мире и общается с ним только через 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, он пожалуй еще менее абстрактно описан.
0
Ну да, по сути вот на этой картинке — Framework Layer это совокупность V и C, это тот слой где формируется нужное представление для каждого компонента (взаимодействие с базой, по HTTP или еще как) а так же контроллеры этих компонентов. А далее уже внутрь идет именно модель. Если сравнивать с ADR — то тут у нас application layer это A, D внутри а R где-то внутри Framework layer. И опять же action-ы работают с DTO а не с HttpRequest. Это будет такие вот application layer сервисы.
В зависимости от потребностей можно какие-то слои объединяться, склеивать, они могут чуть чуть перетекать друг в дружку…
В зависимости от потребностей можно какие-то слои объединяться, склеивать, они могут чуть чуть перетекать друг в дружку…
0
То есть по факту ADR вполне себе нормально ложится на гексагональную структуру:
- Домен остается Доменом (разделение на Core и обычный сейчас не затрагиваем)
- Действия остаются в Application Layer
- Ответчики остаются в Framework/Infrastructure layer
- Добавляется Фронт-Контроллер, «оборачивающий» все HTTP-запросы в DTO (я же правильно понимаю, что это почти то же самое, что и Presentation Model?)
- Действия получают от Доменов точно такие же Presentation Model/DTO и передают их Ответчикам
0
Ну как бы да. Единственное что:
— Presentation Model не есть DTO, DTO это довольно тупой объект-структурка, который просто переносит данные из одного слоя в другой (у меня скажем для этого используются обычные массивчики и stdObject, я делаю классы только для отдельных сложных случаев). Далее потом отдельные штуки уже из этих данных формируют представление и т.д.
— Фронт контроллер так же часть framework/infrastructure layer. Вообще все контроллеры туда ложатся
— контроллеры там все равно есть, помимо экшенов. Они готовят DTO и дергают экшены. Опять же я к примеру далеко не всегда делаю отдельные сервисы-экшены так как обычно это оверхэд.
— Presentation Model не есть DTO, DTO это довольно тупой объект-структурка, который просто переносит данные из одного слоя в другой (у меня скажем для этого используются обычные массивчики и stdObject, я делаю классы только для отдельных сложных случаев). Далее потом отдельные штуки уже из этих данных формируют представление и т.д.
— Фронт контроллер так же часть framework/infrastructure layer. Вообще все контроллеры туда ложатся
— контроллеры там все равно есть, помимо экшенов. Они готовят DTO и дергают экшены. Опять же я к примеру далеко не всегда делаю отдельные сервисы-экшены так как обычно это оверхэд.
0
Еще когда оригинал читал, заметил, что DCI ни к MVC ни к ADR никаким боком не подходит. DCI применим внутри доменной логики, это не общеархитектурный паттерн. Я бы DCI скорее с монадическими вычислениями ассоциировал.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Action-Domain-Responder — доработка MVC под задачи веба