Насколько гранулярной должна быть команда в модели CQ [R] S?

17

Я рассматриваю проект по переносу части нашего SOA на основе WCF на модель служебной шины (возможно, nServiceBus) и использую базовый pub-sub для разделения команд на запросы .

Я не новичок в SOA или даже в моделях шины обслуживания, но признаюсь, что до недавнего времени моя концепция «разделения» была ограничена обычным зеркалированием и репликацией базы данных. Тем не менее, меня привлекает эта идея, потому что она, кажется, обеспечивает все преимущества в конечном итоге непротиворечивой системы, в то же время обходя многие из очевидных недостатков (особенно отсутствие надлежащей поддержки транзакций).

Я много читал на эту тему от Уди Дахана, который в основном является гуру архитектуры ESB (по крайней мере, в мире Microsoft), но одна вещь, которую он говорит, действительно озадачивает меня:

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

[...]

Ключевым элементом CQRS является переосмысление дизайна пользовательского интерфейса, чтобы мы могли уловить намерения наших пользователей, так что предпочтение клиента - это другая единица работы для пользователя, отличающаяся от указания того, что клиент переехал или что он получил состоите в браке. Использование Excel-подобного интерфейса для изменения данных не отражает намерения, как мы видели выше.

- Уди Даан, уточненный CQRS

С точки зрения, описанной в цитате, трудно поспорить с этой логикой. Но, похоже, это идет вразрез с SOA. Предполагается, что SOA (и в действительности сервисы в целом) имеют дело с крупнозернистыми сообщениями, чтобы минимизировать сетевые шумы - среди многих других преимуществ.

Я понимаю, что болтовня в сети менее важна, когда у вас есть высокораспределенные системы с хорошей очередью сообщений и отсутствием багажа RPC, но кажется, что не стоит полностью устранять проблему. Кажется, что Уди почти говорит, что каждое изменение атрибута (то есть обновление поля) должно быть его собственной командой, которую трудно представить в контексте одного пользователя, потенциально обновляющего сотни или тысячи объединенных сущностей и атрибутов, как это часто происходит с традиционным веб-сервис.

Одно пакетное обновление в SQL Server может занять доли секунды при наличии хорошего высокопараметрического запроса, табличного параметра или массовой вставки в промежуточную таблицу; обработка всех этих обновлений по одному медленная, медленная, медленная , и аппаратное обеспечение для баз данных OLTP является самым дорогим из всех масштабируемых / масштабируемых.

Есть ли способ примирить эти конкурирующие проблемы? Я думаю об этом неправильно? Есть ли у этой проблемы известное решение в мире CQS / ESB?

Если нет, то как решить, каким должен быть «правильный уровень» гранулярности в Команде? Есть ли какой-то «стандарт», который можно использовать в качестве отправной точки - вроде 3NF в базах данных - и отклоняться только тогда, когда тщательное профилирование предполагает потенциально значительное повышение производительности?

Или это, возможно, одна из тех вещей, которые, несмотря на несколько сильных мнений, высказанных различными экспертами, на самом деле являются просто вопросом мнения?

Aaronaught
источник

Ответы:

7

На тему «каждое изменение атрибута»

Я думаю, что вы упустили момент. Мистер Уди Дахан говорит, что вы должны зафиксировать намерение пользователя как команду. Конечный пользователь обеспокоен возможностью указать, что клиент переехал. В зависимости от контекста эта команда может содержать идентификацию клиента, новый адрес (разделенный на улицу, номер улицы, почтовый индекс, ...), необязательно новый номер телефона (не редкость при переезде - возможно, не так во всех этих мобильных телефонах) , Это вряд ли один атрибут. Лучший вопрос: «Как мне проектировать команды?». Вы разрабатываете их с поведенческой точки зрения. Каждый сценарий использования, поток, задача, которую пытается выполнить конечный пользователь, будет зафиксирован в одной или нескольких командах. То, что данные идут с этими командами, естественно, когда вы начнете рассуждать о них более подробно. Остерегайтесь данных, которые интерпретируются какможет быть признаком того, что вам нужно разделить команду. Я надеюсь, что вы никогда не найдете этот стандарт в отношении детализации команд. Хороший вопрос, хотя!

Ив Рейнхаут
источник
Это определение все еще кажется мне очень произвольным; Концептуальная модель CSR может объединять предпочтительный статус и военное положение так же, как вы объединяете адрес и почтовый индекс. Я не хочу расставаться, мне просто кажется, что для того, чтобы по-настоящему понять, отличаются ли они поведением, вы должны быть в состоянии предсказать последующие эффекты, и OTOH всю идею ESB и CQS и pub / Суть в том, что вы не должны знать или заботиться о том, что происходит вниз по течению. Спасибо за ваш ответ, я ценю это, хотя я не могу сказать, что чувствую себя более просветленным ...
Aaronaught
@Aaronaught: определение является произвольным. Степень детализации Команды должна соответствовать тому, что имеет смысл для вашего конкретного сценария . Там не один размер подходит всем. Существует несколько рекомендаций, таких как сопоставление команд для использования вариантов или задач или действий, доступных в пользовательском интерфейсе. Другое - отдавать предпочтение более детализированным командам по сравнению с менее детализированными командами (в частности, как сказал Ив, опасаясь данных, которые интерпретируются как поток логического управления) - но нет жесткого и быстрого правила. Существует ли реальный сценарий, когда «один пользователь потенциально обновляет сотни или тысячи объединенных сущностей и атрибутов»?
Квентин Старин
В этом весь смысл! Не смешивайся. Разделите по поведению! Не помещайте данные в команду, которая не соответствует намерению команды / конечного пользователя. И дело не в нисходящих системах.
Ив Рейнхаут
@qes: В наших системах есть несколько таких сценариев, очень реальных и очень необходимых. Чтобы сформулировать это как можно проще, им необходимо изменить целые последовательности данных, и эти последовательности имеют смысл только как последовательности. Конечно, они обычно не делают эти изменения запись за записью, они применяют некоторый алгоритм к большей части этого и затем исправляют несколько исключений. Может быть, это просто неподходящий сценарий для CQS, но это решение - лишь часть моего более широкого вопроса.
Aaronaught
1
@Qes: достаточно справедливо, и это ответ сам по себе. Я, конечно, понимаю концепцию логической операции (именно так моделируются существующие сервисы), я думаю, я просто обеспокоен тем, что CQS, похоже, меняет несколько правил относительно того, как вы должны определять операцию. «Традиционная» SOA, кажется, начинается с самого грубого возможного определения и движется вниз по лестнице абстракции при необходимости; моё понимание CQS до сих пор, кажется, указывает на обратное, начнем с самого детального из возможных определений и абстрактных, если оно слишком похоже на RPC или поток управления.
Aaronaught
2

Уди пытается донести мысль о том, что CQRS - это больше, чем просто CRUD. Почему я создал эту запись? Почему я меняю эту запись? Почему он удаляется / помечается как удаленный?

Команды должны соответствовать действиям / сценариям использования, которые пользователь выполняет с системой, и выражать намерение действия, а не просто говорить «измените это». Кроме того, может показаться, что он более мелкозернистый, но он может быть гораздо грубее, чем кажется на первый взгляд. Например, повышение статуса до золотого может включать изменение нескольких атрибутов, а ряд других агрегатов может даже реагировать и изменяться в ответ на соответствующее событие.

CQRS предназначен для захвата языка бизнеса на уровне обслуживания, поэтому пользовательскому интерфейсу не нужно беспокоиться о том, что произойдет, когда я произвожу повышение статуса Gold, или посылка будет помечена как недоставленная перевозчиком, или сотрудник был повышен руководителю технологической группы. Ну, технически я сейчас говорю о Event Sourcing, но вы меня поняли. Есть более четкие сообщения, но они не обязательно более детализированы, чем стандартные CUD.

Майкл Браун
источник