Архитектурный вопрос

В результате предыдущего поста ( Архитектура: простой CQS ) я думал, как я могу построить простую систему, которая достаточно гибок, чтобы быть расширенным позже.

Другими словами: я не вижу необходимости в полноценной CQRS сейчас, но я хочу, чтобы позже, если потребуется, легко развить ее.

Итак, я подумал о том, чтобы отделить команды от запросов , но оба основаны на одной базе данных.

Часть запроса будет простой: служба данных WCF, основанная на представлениях, для которых легко запрашивать данные. Ничего особенного.

Командная часть - это что-то более сложное, и вот идея:команды, конечно, выполняются асинхронно, поэтому они не возвращают результат. Но контроллеры моего сайта ASP.NET MVC часто нуждаются в обратной связи от команды (например, если регистрация участника прошла успешно или нет). Поэтому, если контроллер отправляет команду, он также генерирует идентификатор транзакции (guid), который передается вместе со свойствами команды. Служба команд получает эту команду, помещает ее в таблицу транзакций в базе данных с состоянием «обработка» и выполняется (с использованием принципов DDD). После выполнения таблица транзакций обновляется, так что состояние становится «завершено» или «не удалось», а также другая более подробная информация, такая как первичный ключ, который был сгенерирован.

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

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

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

Считаете ли вы какие-либо недостатки в этом подходе? Другие идеи или предложения?

Спасибо!

Lud