Доменное имя для событий, которые еще не произошли

Question

Хорошо, я понимаю, что название звучит странно. Событие всегда должно быть за то, что произошло, например, OrderCreated, ParcelShipped и т. Д.

Однако мне интересно, есть ли у кого-нибудь мысли по поводу следующей проблемы.

Рассмотрим приложение по подбору персонала, которое моделирует людей и их работу. Ради простоты, у человека может быть множество рабочих мест, и они могут быть закончены на свидании. У человека есть операция EndJob, которая принимает endDate.

Если endDate будет в будущем, каким будет событие домена?

JobEndedEvent (это не так)

JobEndDateAddedEvent (это довольно технически)

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

Любые мысли приветствуются ... Спасибо.

Answer 1

Если endDate будет в будущем, каким будет событие домена?

JobCompletionScheduled * * 1006

Мы приняли решение сейчас, но дата вступления в силу в будущем. Это совершенно нормальное занятие в сфере бизнеса, и само решение полезно для сбора бизнес-аналитики.

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

Answer 2

Хотя есть событие, которое происходит, когда вы указали, что задание «кто-то» «завершается», давайте назовем его «jobEndIntentionEvent», существует также неявное событие, которое происходит, когда задание на самом деле заканчивается, - «jobEndEvent».

Теперь контекст, ограниченный исходным кодом, возможно, не должен вызывать этот "jobEndEvent", чтобы воздействовать на него сам. У вас может быть несколько ограниченных контекстов, которые действительно заинтересованы только в знании этого события. Так это должно поднять это вообще? Или же все остальные ограниченные контексты должны играть на картах, с которыми они сдаются - то есть слушать «jobEndIntentionEvent» и реализовывать код, который запускается, когда будет получено событие, которое они хотели бы услышать («jobEndEvent»)?

Или должен быть ограничен исходный контекст и запускать это «событие интеграции» для всех.

Или, в качестве альтернативы, более удачным решением было бы то, что у нас есть ограниченный контекст планирования, который является подписчиком на «jobEndIntentionEvents» и тому подобное, и он знает, как преобразовать их в РЕАЛЬНЫЕ события, о которых люди действительно заботятся - «jobEndEvents».

Answer 3

Что ж, с точки зрения домена, вы, вероятно, говорите о JobTerminationScheduledEvent, потому что с языковой точки зрения вы уведомляете другие контексты о планировании окончания задания.

Это не совсем так, расписание может измениться, и вы оставите на усмотрение других контекстов, как они будут обрабатывать такую ​​информацию.В данном контексте может показаться, что планирование является достаточной информацией, чтобы считать, что задание закончится к указанной дате.

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

В конце концов, вашконтекст на самом деле выражает то, что произошло: ничего конкретного.У вас есть запланированная дата для этого действия, но оно еще не произошло.