Есть ли какие-либо потенциальные недостатки в такой тесной связи?
Вам нужно быть немного осторожнее с точки зрения понимания направления ваших зависимостей.
В частности, если вы пытаетесь интегрировать с клиентами, которые не контролируют , то вы захотите договориться о контракте - семантике и схеме сообщений - который вы не можете изменить в одностороннем порядке.
Это означает, что представления относительно фиксированы, но у вас есть много свободы в том, как вы реализуете создание этого представления. Вы даете обещание клиенту, что он может получить представление отчета 12345, и он будет иметь удобное расположение информации. Но то, является ли это представление чем-то, что вы производите по требованию, или чем-то, что вы кешируете, и то, как вы его создаете, полностью зависит от вас.
На этом уровне вы на самом деле не связываете своих клиентов с моделью вашего домена. ; вы связываете их с вашими представлениями / отчетами, то есть с вашей моделью data . И в мире CQRS это соединение с моделью чтения, а не с правильной моделью.
С точки зрения команд я рассматривал такой подход, как ...
Я собираюсь мягко предположить, что у автора в 2015 году не было особенно хорошего понимания REST по сегодняшним стандартам.
Основная проблема c в том, что автор не признать, что кэширование является REST-ограничением ; и при разработке наших протоколов HTTP необходимо учитывать, как компоненты общего назначения понимают аннулирование кэша .
Обычно для команды (имеется в виду «сообщение, предназначенное для изменения представления ресурса»). ), вы обычно хотите, чтобы target-uri HTTP-запроса совпадал с идентификатором основного ресурса, который изменяется.
POST /foo/123/command
Не особенно полезен с точки зрения аннулирования кэша, если никто никогда не отправляет GET /foo/123/command запрос.