DDD как методология системного анализа, самая большая проблема заключается в том, как практиковать в проекте. На практике неизбежно возникает много проблем. «Шаблон» — это распространенный метод в области системной архитектуры, который может помочь разработчикам и архитекторам ссылаться на существующие проблемы, когда они сталкиваются с некоторыми трудными или незнакомыми проблемами. Зрелый опыт и решения, чтобы элегантно решать проблемы в своих проектах.
С самого начала этого выпуска я начну знакомить с некоторыми общими шаблонами в DDD, включая предысторию, функцию, преимущества и недостатки этих шаблонов, а также моменты, на которые необходимо обращать внимание в процессе их использования. Главным героем этого времени является CQRS, который на китайском языке называется Command Query Responsibility Separation.
Зачем это использовать?
Нет сомнений в том, что «домен» занимает центральное место в DDD, DDD реализует бизнес-логику и процессы посредством взаимодействия между объектами домена, разделяет бизнес-логику многоуровневым образом и поддерживает ее отдельно, тем самым контролируя сложность самого бизнеса. Проводить.
Но как бизнес-система, сопутствующие функции «запроса» также незаменимы. При реализации различных функций запросов часто обнаруживается, что их сложно реализовать с помощью модели предметной области. Предполагая, что пользователю нужна функция запроса для информации, связанной с заказом, отображается список результатов запроса. Данные в списке поступают из определенных полей в нескольких объектах домена, таких как «Заказ», «Товар», «Категория» и «Адрес доставки». Если такая сцена все же инкапсулирована объектами предметной области, это будет очень хлопотно, а во-вторых, она не слишком тесно связана с предметными знаниями.
В настоящее время CQRS может решить вышеуказанные проблемы как модель, так что же такое CQRS? Как этого добиться?
Что такое CQRS?
CQRS — Разделение ответственности за запросы команд, как следует из названия, это режим, который отделяет команду от запроса. query легко понять, это «запрос», о котором мы упоминали ранее, так что же такое команда?
CQRS делит операции в системе на две категории, а именно «Команда» и «Запрос». Команда — это общий термин для операций, которые вызывают изменение данных, то есть операции, которые мы часто называем добавлением, обновлением и удалением, являются командами. Запрос — это то же самое, что и буквальное значение, то есть операция, которая не изменяет данные, а только ищет данные в соответствии с определенными условиями.
Основная идея CQRS состоит в том, чтобы разделить эти два разных типа операций и реализовать их в двух отдельных «сервисах». Под «службой» здесь обычно понимаются два независимо развернутых приложения. В некоторых особых случаях его также можно развернуть на разных интерфейсах в одном приложении.
Источники данных, соответствующие Command и Query, также должны быть независимы друг от друга, то есть операция обновления выполняется для одного источника данных, а операция запроса — для другого источника данных. Увидев это, у вас может возникнуть вопрос: теперь, когда источники данных разделены, как синхронизировать данные? Давайте двигаться дальше.
Внедрить CQRS
Давайте сначала посмотрим на архитектурную схему CQRS:
Как видно из рисунка, когда система команд завершает операцию обновления данных, она уведомляет систему запросов через «события предметной области». Система запросов обновляет собственный источник данных после получения события. Все операции запросов выполняются через интерфейс, предоставляемый системой запросов.
С точки зрения схемы архитектуры реализация CQRS не кажется сложной, многие разработчики считают, что это не более чем «добавление, удаление и изменение» системы и базы данных, а также «запрос» системы и база данных особое место. Но есть много проблем и деталей, которые необходимо решить, чтобы действительно использовать CQRS.
Проблемы с CQRS
дела
На самом деле, подумайте об этом хорошенько, и вы быстро обнаружите одну из самых больших проблем, с которыми приходится сталкиваться CQRS: транзакции. В исходном едином процессе система с одним источником данных, опирающаяся на характеристики транзакций реляционной базы данных, может обеспечить целостность данных. Но в CQRS все изменилось.
Когда командная сторона завершает обновление данных, она должна уведомить систему на стороне запроса в виде события.Существует определенная разница во времени.Если у вашего бизнеса очень высокая целостность данных в реальном времени, то CQRS может не подойти для тебя.
Во-вторых, событие, вызванное командой, может потребовать обновления нескольких моделей данных на стороне запроса, что также может привести к сбою. После сбоя обновления данные будут находиться в несогласованном состоянии в течение длительного времени, что потребует внешнего вмешательства. Это также следует учитывать перед использованием CQRS.
Глядя на CQRS с точки зрения транзакций, вы должны признать, что проблема, по сути, является проблемой возможной согласованности, поэтому, если у вашей команды нет большого опыта в этой области, вам нужно заранее изучить и накопить некоторый опыт.
Проблемы с инфраструктурой и техническими возможностями
Еще одна проблема с CQRS заключается в том, что нет зрелого и простого в использовании фреймворка.Axon может быть одним из них, но сам по себе Axon — тяжеловесный и очень зависимый фреймворк. Внедрение Axon для CQRS — непростая задача, поэтому большую часть времени вам придется внедрять CQRS самостоятельно.
Зрелая и надежная система CQRS предъявляет определенные требования к инфраструктуре: например, для реализации доменных событий необходимо надежное промежуточное ПО для обработки сообщений. В противном случае несоответствие данных, вызванное частыми потерями, приведет к опустошению эксплуатационного и обслуживающего персонала. Вышеупомянутые проблемы распределенных транзакций и окончательной согласованности также требуют поддержки специализированного промежуточного программного обеспечения или фреймворков, которые не только повышают требования к инфраструктуре, но и предъявляют более высокие требования к разработке, эксплуатации и обслуживанию.
В процессе разработки необходимо добавить поддержку событий, а также определенные изменения в мышлении о системном дизайне. При определении команды необходимо спроектировать соответствующее событие, спроектировать тип и структуру данных события, поэтому это также выдвигает новые требования к команде разработчиков в этом отношении.
Поэтому, прежде чем приступить к использованию CQRS, вы можете провести всестороннюю оценку инфраструктуры вашей команды и возможностей разработки, как можно скорее выявить недостатки и внести целенаправленные улучшения и усовершенствования, чтобы избежать определенных проблем в процессе разработки.
Дизайн модели запроса
Хотя CQRS разделяет модель предметной области и модель данных, обслуживающую функцию запроса, это означает, что нам нужно разработать другой набор моделей данных для функции запроса. Вообще говоря, относительно просто спроектировать в соответствии с данными, требуемыми функцией запроса, то есть разработать представление данных для каждого интерфейса запроса и обновить связанное представление данных при получении событий предметной области.
Однако проблема, вызванная этим простым подходом, заключается в том, что когда интерфейсов запросов становится все больше и больше, им будет трудно управлять, по-прежнему необходимо централизованно управлять запросами, принадлежащими БК, как контекстом всей системы запросов в соответствии с идея разделить БК в DDD или просто Самостоятельно сделать микросервис. Таким образом, даже с введением CQRS нам по-прежнему необходимо проектировать интерфейс запроса, используя подход, ориентированный на предметную область.
Отношение к источнику событий
Event SourcingЭто шаблон архитектуры предприятия, предложенный Мартином Фаулером. Проще говоря, он будет хранить все бизнес-поведения, сгенерированные системой, в форме только для добавления, которая широко известна как «текущая учетная запись». Его преимущество заключается в том, что его можно «отследить», поскольку он записывает информацию о каждом изменении данных, что очень удобно, когда есть ошибка или когда вам нужно устранить проблемы с бизнес-данными. Но его недостаток также очевиден, то есть ему нужно делать много вычислений, когда вам нужно запросить самые свежие данные, такие как данные об остатке на счете.
Источники событий обсуждаются во многих статьях, в которых CQRS рассматривается как два шаблона, которые необходимо использовать вместе. Но с точки зрения моего фактического использования эти два режима не обязательно связаны между собой. Командная сторона должна заботиться только об успешном обновлении модели предметной области и использовать объекты предметной области, такие как Aggregate, для обеспечения целостности данных, в то время как сторона запроса заботится об обновлении соответствующей модели данных после получения событий предметной области. Для таких функций, как "возврат" обязательных требований нет. Это правда, что Event Sourcing может помочь нам построить более стабильную и мощную систему CQRS, но сложность самого Event Sourcing может быть больше, чем у CQRS, поэтому при отсутствии особых потребностей CQRS и Event Sourcing несовместимы. быть связаны вместе.
Различные типы механизмов хранения данных
Это на самом деле не проблема, но больше проблем или преимущество. Поскольку модель домена и модель данных разделены, это означает, что мы можем использовать механизм хранения данных, который ближе к требованиям запроса, таких как NoSQL, Elasticsearch и т. Д. На стороне запроса.
Более распространенная ситуация заключается в том, что сторона Command по-прежнему использует традиционную реляционную базу данных, но использует выделенное хранилище данных для этих специальных запросов. Например, в некоторых сценариях полнотекстового поиска на основе ключевых слов, если все еще используется реляционная база данных, легко столкнуться с проблемами производительности из-за SQL-запросов, подобных подобным. В настоящее время вы можете заменить хранилище данных механизмом поиска, таким как ElasticSearch, и извлекать запросы по ключевым словам с помощью обратного индексирования, что значительно повысит производительность. В других сценариях, требующих запроса неструктурированных данных, Json является хорошим форматом хранения.Хотя более новые версии реляционных баз данных обеспечивают хранение и запросы в формате Json, базы данных документов, такие как MongoDB, более просты и эффективны, преимущество гибкости на стороне запроса еще более очевидно.
резюме
CQRS — это шаблон, который часто упоминается в DDD, его цель — отделить модель предметной области от функции запроса, чтобы некоторые сложные запросы могли избавиться от ограничений модели предметной области и отображать результаты запроса в более простой форме DTO. В то же время различные структуры хранения данных разделены, что позволяет разработчикам более свободно выбирать механизмы хранения данных в соответствии с функциями и требованиями запроса.
Точно так же, в то время как CQRS обеспечивает архитектурную свободу и удобство, он также неизбежно вводит дополнительные требования к сложности и навыкам, такие как распределенные транзакции, управление промежуточным программным обеспечением сообщений, проектирование модели данных и т. д. Перед этим необходимо тщательно проанализировать возможности команды и существующую структуру. , и внести необходимые исправления в недостатки. Если существующая системная логика относительно проста, всего лишь какой-то CRUD, то CQRS не рекомендуется. Однако, если ваша бизнес-система уже очень велика, бизнес-процесс сложен, а логика громоздка, вы можете попробовать использовать CQRS для разделения команд и запросов, чтобы сделать границу между моделью предметной области и моделью данных более четкой.
Добро пожаловать, чтобы обратить внимание на мою учетную запись WeChat «Давайте поделимся с людьми золотой иглой», чтобы получать больше качественных статей.