Мне интересно, как моделировать календарь с использованием DDD и CQRS. Моя проблема заключается в увеличении числа событий. Я рассматриваю Calendar как Aggregate Root, который содержит события (события календаря). Я не хочу использовать ReadSide в моих командах, но мне нужен способ проверки конфликтов событий на уровне домена.Агрегатный корень, включающий огромное количество детей
Мне интересно, как моделировать календарь с использованием DDD и CQRS. Моя проблема заключается в увеличении числа событий.
Наиболее распространенный ответ на «долгоживущие» агрегаты - это разбить эту жизнь на эпизоды. Примером этого могут быть временные учетные записи, которые бухгалтера будут закрывать на уровне end of the fiscal year.
В вашем конкретном случае, возможно, не «Календарь» так же, как «февральский календарь», «календарь в марте» и т. Д., При любом зерне, подходящем для вашего домена.
Im не уверен, что Im верно относительно DDD aproach с точки зрения проверки. Я считаю, что дело не в том, чтобы позволить модели вступить в недействительное состояние
Да, но неверное состояние - сложная задача определить. Udi Dahan предложил this observation
Микросекундная разница во времени не должна иметь значения для основных бизнес-моделей поведения.
Более лаконично, команды обработки с последующей обработкой команды B производит действительное состояние, то оно также должно быть верно, что вы в конечном итоге команда обработки B, а затем А.
Давайте выбрать «событие столкновений ". Предположим, что мы обрабатываем две команды scheduleMeeting(A) и, а модель домена понимает, что A и Bcollide. Загадка: как мы убеждаемся, что календарь остается в правильном состоянии?
Без ограничения общности мы можем перевернуть монету, чтобы решить, какая команда прибывает первой. Моя монета вышла на хвост, так что команда B прибывает первым.
on scheduleMeeting(B):
publish MeetingScheduled(B)
Теперь прибывает команда для встречи A.Если ваши действительные календари не разрешают конфликты, то ваша реализация должна выглядеть как
on scheduleMeeting(A):
throw DomainException(A conflicts with B)
С другой стороны, если вы принять идею о том, что команды прибывают не должны влиять на результат, то вам необходимо рассмотреть другой подход. Возможно
on scheduleMeeting(A)
publish MeetingScheduled(A)
publish ConflictDetected(A,B)
То есть, совокупный календарь моделируется отслеживать не только запланированные события, но и конфликты, которые возникли.
Смотрите также: aggregates and RFC 2119
Событие также может быть объединенным корнем. Я не знаю вашего бизнес-ограничения, но я думаю, что если два события colide вы могли бы уведомить пользователя как-то о ручных действиях. В противном случае, если вы действительно действительно им нужно не запыхаться, вы могли бы использовать моментальные снимки, чтобы ускорить огромный календарь AR.
Я не хочу использовать ReadSide в моих командах, но мне нужен способ проверки конфликтов событий на уровне домена.
Вы не можете запросить модель чтения внутри обработчика агрегатной команды. Для обнаружения столкновений я создаю специальный DetectColisionSaga, который подписывается на событие EventScheduled и что он может проверить (возможно, как асинхронно, если много событий), если произошло столкновение, и как-то уведомить пользователя.
Спасибо, но ACCESSING прочитать сторону от рассматриваемой области хорошей практикой на всех? – ayeo
Что вы подразумеваете под "domain"? Вы имеете в виду сторону для записи? –
Да, в основном с точки зрения этого вопроса, я имею в виду сторону записи. Насколько я понимаю Команды, которые должны выполняться (обработчиками) непосредственно на моделях домена. – ayeo
Благодарим за ответ. Ваша идея о смене календаря в отдельные месяцы кажется мне совершенно верной. Я не уверен, что Im правильно об DDD aproach с точки зрения проверки. Я считаю, что дело не в том, чтобы позволить модели войти в недействительное состояние, что подразумевает необходимость знать все собственные события по Календарю (как Agreggate Root). – ayeo
Я думаю, вам нужно объяснить немного более подробно, как система могла бы использовать конечную согласованность, потому что, как вы ее описали, вам все еще нужны большие совокупные границы, чтобы обнаружить, что конфликт даже произошел. С возможной согласованностью события могут быть отдельными агрегатами, и вы можете полностью избавиться от сбора событий в календаре (заменив его на запрос). – plalx
Когда я занимался каким-то управлением ресурсами, у меня появилась концепция дня. Не к моему большому удивлению, другие практикующие пришли к такому же выводу. Вы можете иметь как событие, так и день, и проверить, совместимы ли они (день имеет доступность, а событие может приземляться до нескольких дней). –