Cqrs web api mvc или микросервис
Мы работаем над созданием новой системы (.Net), которая объединит существующие 6 систем клиента в одну. Текущие 6 систем имеют разные базы данных. При обсуждении дизайна веб-API клиент спросил, можем ли мы следовать шаблону CQRS. Я планировал использовать один веб-API, разбивая контроллеры на Query и Command, которые, в свою очередь, работают со службами (классами c#), которые также разбиты на Query и Command.
Во время одной из встреч другой разработчик упомянул, что нам следует обратить внимание на микросервисы, поскольку клиент упомянул CQRS. Эти два связаны, я имею в виду, вам нужны микросервисы для этого? Я думал, что микросервисы здесь будут излишними, так как в конце концов будет одно приложение с одной базой данных, а не 6 независимых систем, которые могут совместно использовать несколько API. Единственным преимуществом, которое я мог видеть в микросервисах, было развертывание, но помимо этого единственный API, который я считал приемлемым.
Ответы 1
Вы столкнулись с классической проблемой. Сохраняем ли мы что-то вместе ради сплоченности или разделяем это по какой-то причине.
В вашем случае вы сталкиваетесь с физической границей: достаточно ли разделяют «сторона чтения» и «сторона записи», чтобы их стоило размещать в пределах одной и той же физической границы (одна единица развертывания) или стоит размещать их в двух отдельные физические единицы (две единицы развертывания).
В сценарии CQRS физическое разделение имеет смысл по нескольким причинам.
- Модели часто бывают разные. Модель чтения оптимизирована для того, что предоставляется пользователю или системе, которой нужна информация, в то время как модель записи обычно богаче, поскольку она изменяет предметную область, требует проверки и применения других бизнес-правил.
- Чтения обычно чаще появляются в решении, поэтому для них требуется другой набор коэффициентов масштабирования. С этими факторами можно справиться, если они не зависят от стороны записи.
Кроме того, если ваш CQRS «чистый» или близок к нему, это означает, что доступ «изменить» будет попадать в другое хранилище данных, чем ваш доступ «чтения».
Даже если они попадут в один и тот же магазин, все равно может быть причина их разделить. В облачном мире это означает наличие отдельных микросервисов.
Тем не менее, подход, который я считаю хорошо работающим, заключается в следующем: создайте свое логическое решение для различных потребностей. Сначала создайте свое физическое решение для совместного размещения этих логических потребностей в одном пространстве (например, один микросервис). . Если масштаб, производительность, тестирование, связь или другие факторы предполагают физический перерыв, то сделайте это! Переходите на отдельные микросервисы.
В конце концов, дело доходит до того, будет ли эта вещь работать и работать хорошо сейчас или всегда в одном микросервисе (модуле развертывания) или будет ли она работать лучше позже, в отдельных физических экземплярах (микросервисах).
В заключение, логическая установка/реализация определенно требует некоторого обдумывания заранее. О физическом также следует думать, но изначально оно менее важно. Разбивая логическую структуру на физические дома, вы обнаружите, что это проще сделать, чем если бы вы изначально начали с физической структуры.