Почему модель домена не должна использоваться в качестве ресурсов в REST API?

Я столкнулся с утверждением о том, что модель домена, разработанная в соответствии с DDD, не должна использоваться в качестве ресурсов в REST API (source).

Понятно, что REST API - это контракт приложения, в то время как модель домена является частью реализации, и поэтому лучше всего разделить эти две вещи, так что изменение в модели домена автоматически не подразумевает изменение API REST.

Однако, я думаю, что в случае небольших проектов (где REST API имеет только одного потребителя - интерфейс javascript, разработанный одной командой), преимущества наличия отдельных моделей не оправдывают затраты на разделение моделей (разные классы - модель домена и представления ресурсов и код сопоставления между моделями). Очевидно, что на уровне домена не может быть ссылок на конкретный код инфраструктуры REST (чтобы разделить проблемы).

Следует ли разделять домен и модели REST?

Ответ 1

При использовании DDD API REST всегда должен быть отделен от модели домена.

Основной причиной этого является упрощение - вы не хотите просачивать сложность модели домена через API для клиентов. В противном случае клиенты должны знать о нюансах и тонкостях вашего домена, что, скорее всего, затрудняет использование API.

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

Однако, я думаю, что в случае небольших проектов (& hellip;) преимущества наличия отдельных моделей не оправдывают затраты на разделение моделей (& hellip;).

Я согласен с тем, что существуют проекты, в которых разделенная модель домена и REST API являются чрезмерными. Однако эти случаи не являются кандидатами на DDD, потому что вы не будете использовать DDD, чтобы оправдать его стоимость.

Ответ 2

Почему модель домена не должна использоваться в качестве ресурсов в REST API?

Потому что Интернет - это совершенно другой мир, чем ваш основной доменный уровень. Методы в ваших сущностях особенно трудно перевести, поскольку HTTP имеет только несколько глаголов. Если вы хотите разоблачить свое приложение через REST, вы должны обучить процессы своего домена HTTP, и это обычно означает компрометацию и разработку ресурсов, отличных от ваших объектов домена.

Конечно, вы должны находить термины из Ubiquitous Language в сообщениях, обмениваемых HTTP-клиентом и сервером, и в протоколе приложений домена, если вы делаете HATEOAS, но сеть обязательно исказит ваши представления домена.

Точка REST заключается не в том, чтобы воссоздать высококачественную модель вашего домена и его процессов, а в том, чтобы доставлять их по HTTP-совместимому способу, теряя при переводе как можно меньше. Тем не менее он остается переводом.

Ответ 3

Я думаю, что еще одна вещь, которую следует учитывать, - это то, кто использует ваш REST API. Если вы разрабатываете интерфейс для приложения, вы можете сказать, что все еще происходит в пределах 1 ограниченного контекста. Просто часть живет в клиенте /javascript. В этом случае я думаю, что имеет смысл разоблачить вашу модель в вашем отдыхе api.

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

Ответ 4

Вы можете привязать свою бизнес-логику к ресурсам REST на основе вашей модели домена. Например, всякий раз, когда кто-то устанавливает is_published = 1, вы можете уведомить администратора, выполнить дополнительную проверку и т.д., Подключившись к событию или мутатору. Иногда вещи могут быть слишком сложными и странными, чтобы сделать это, поэтому вы можете пометить определенные атрибуты как немодифицируемые, а затем создать настраиваемые действия, чтобы изменить их, которые вы раскрываете, если это имеет смысл. Я думаю, что если вы правильно спроектируете, вам даже не нужны эти "пользовательские действия". Facebook не использует никаких графических API, я не думаю. Я думаю о разработке структуры, основанной только на демонстрации уровня модели, я все еще думаю, что это хорошая идея.

Ответ 5

Я думаю, что основным преимуществом REST API является предоставление сервиса (обычно на стороне сервера, а не SPA) сторонним REST-клиентам. Если вы используете HATEOAS и другие решения с самоописанием сообщений, такие как RDF, клиенты REST будут ломаться намного сильнее из-за изменений в REST API. Для небольших проектов - "где REST API имеет только одного потребителя - интерфейс javascript, разработанный одной командой", - я не думаю, что стоит иметь правильный REST API. Большинство людей используют его упрощенную версию, которую я называю CRUD API, и они могут быть хороши для этих проектов.

Может быть отображение 1:1 между ресурсами CRUD и объектами домена модели анемичного домена. Если мы говорим о реальных объектах (а не структурах данных) с использованием не только методов CRUD, то вы должны выполнить перевод между resource.verb и object.method, например:

POST /dogs/{id}/barking
 -> domain.dog.bark()

Если мы говорим о более сложных вещах, связанных с несколькими объектами домена и единицей работы (транзакциями), то вам нужно добавить еще один слой для служб приложений, в противном случае вы бы перенесли всю сложную операцию, включая обработку транзакций, на клиент. В этих случаях вы переводите между resource.verb и applicationService.operation, например:

POST /dogs/{id1,id2,..}/barking
 -> dogService.multiDogBark(...)
 -> UnitOfWork{domain.dogs[ids[i]].bark()}

Я думаю, что большинство разработчиков путают этот подход CRUD-сервисов + модель анемичной доменной системы с подходом REST-сервисов + доменной модели, поэтому задают этот вопрос и поэтому существует множество структур "REST", которые добавляют объект домена 1:1 - ресурс CRUD. отображение или, может быть, даже объект ORM - отображение ресурсов CRUD. Я нахожу эту тенденцию очень разрушительной, и я думаю, что основная причина в том, что разработчики изучают определенные технологии только поверхностно из коротких статей или сайтов вопросов и ответов вместо чтения книг и диссертаций, где они могут получить глубокие знания по актуальной теме. Я думаю, что это проблема поколения Y+, из-за которой мы теряем способность читать длинные тексты из-за использования цифровых технологий. Мы обусловлены мгновенным вознаграждением вместо отложенного вознаграждения, которое дает длинный текст...