2010-10-01 2 views
13

CQRS включил меня в режим мышления. Я пытаюсь запустить новый проект с идеями CQRS. Главное, что мне нравится, -
1) разделение запроса и команды. Проблемы с доменом были проблемой.
2) Использование хранилища событий для аудита - я не буду использовать его для воспроизведения - по крайней мере, не сейчас.События CQRS и домена

Я хорошо с стороне запроса, и я все еще есть некоторые вопросы по доменным События

Если команда приводит Updation из нескольких агрегатных Roots (Исх. Заказ и OrderDetail) Я буду иметь их область видимости под UnitOfWork (транзакционный). Теперь каждый домен отвечает за публикацию событий, когда происходит изменение его состояния.

скажем, команда изменяет 3 записи заказаDetail. Каждый OrderDetail опубликует 2 события. В итоге у нас есть 6 событий.

a) Если я публикую события, как только я внесли изменения в объект домена (но не совершил транзакцию), как мне отменить события, которые были опубликованы (и, возможно, были использованы абонентами)

  • Что я могу придумать, так это держать события, которые будут опубликованы в списке «под одной областью работы», и после того, как был вызван коммит по транзакции, сохраните его и опубликуйте. Звучит ли это что-то одно.

б) Если изменения в OrderDetail требует, чтобы некоторые изменения также имеют место в Приказе Совокупный Root затем
I) Если я основываю эти изменения путем обработки событий, опубликованных OrderDetail Совокупности? Напр. скажем, две детали заказа были удалены. Это делает статус заказа от «предпочтительного» до «Не предпочтительным». ii) Что делать, если ошибки события и не обновляют состояние заказа. Если заказ остается предпочтительным, он отправляется через 2 дня.

Добавление другого вопроса
с) «событием домена является источником всех изменений состояния приложения» или они «Результат всех изменений состояния приложения»

Спасибо заранее,

The Mar

+0

Я бы посоветовал отправить такие вопросы в Google Group по DDD/CQRS. Там больше практикующих. –

ответ

10

a) Вы не должны публиковать события до совершения транзакции, уведомление о происшествии означает, что произошло , и, следовательно, причина, по которой они все на med in pass tense (например, OrderClearedEvent). Также в случае, если вам нужно «вернуть» событие, вы должны предпринять корректирующие действия, то есть не удалять событие, вы должны инициировать новое событие, которое корректирует эффекты события, которое вы хотите вернуть.

b) кажется, что это скорее проблема в том, как вы моделируете сущности и команды, что угодно. Я не могу думать о причине, почему OrderDetail бы AggregateRoot, но я не знаю свой домен ...

с) Команда приведет, по крайней мере, одно события публикуемой

Надеются, что это помогает :) Как сказал Ринат , группа google - лучшее место для вопросов, а также посмотрите на cqrsinfo.com и пример кода из github.com/MarkNijhof/Fohjin и github.com/gregoryyoung/m-r

+0

Благодарим за ответ. Я использовал группы DDD/CQRS и NCQRS google, о которых упоминал Ринат. Там много хорошего обсуждения. – TheMar

+0

Axon - хороший источник информации и примеров, если вы находитесь в мире Java. https://github.com/AxonFramework – Kimble

Смежные вопросы