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

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

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

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

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

[...]

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

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

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

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

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

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

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

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

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

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

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

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

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