Блог

Ситуация:

Для работы с доменными событиями Джимми Богарт предложил метод хранения событий в агрегатах.

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

Доменная служба не должна иметь состояния (без состояния). В этом случае, теоретически, диспетчер событий IDispatcher должен быть введен в конструктор такой службы.

Вопрос:

Чтобы избежать внедрения в доменную службу диспетчера событий, предлагаемые альтернативные подходы являются правильными:

1. Сохранение в доменной службе событий последней операции. Однако это нарушит принцип отсутствия состояния для доменной службы.
2. Возвращает список событий из метода обслуживания на основе результатов операции (в методе возврата или другим способом, в зависимости от возможностей языка программирования).

Примечание: этот пост был написан около пяти лет назад. Возможно, вы захотите ознакомиться с его более недавним (и более подробным): Жизнь за пределами распределенных транзакций: реализация отступника

Доменная служба не должна иметь состояния

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

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