Насколько гранулированным должно быть доменное событие?
Мне интересно, насколько гранулированным должно быть доменное событие?
Например, у меня есть что-то простое, например, изменение firstName, secondName и адреса электронной почты на странице профиля. Должен ли я иметь 3 разных доменных события или только одно?
При крупномасштабных событиях в домене, когда я добавляю новую функцию, мне нужно создать новую версию события, поэтому я должен добавить новый тип события или сохранить версии событий в хранилище событий. По мелким детальным событиям в домене у меня нет этих проблем, но у меня слишком много маленьких классов. Как вы думаете, что является лучшей практикой в этом случае?
2 ответа
В чем проблема со многими классами? В самом деле, почему так много разработчиков боятся иметь слишком много классов? Вы определяете столько классов, сколько необходимо.
Событие домена сигнализирует, что домен изменился определенным образом. Он должен содержать всю соответствующую информацию и принимать во внимание тот факт, что событие также является DTO. Вам нужны четкие события, но разработчик должен решить, насколько гранулированным или универсальным является событие.
Размер не имеет значения, однако, если ваше событие "весит" 1 МБ, возможно, у вас есть проблема. И количество классов не является критерием дизайна событий домена.
Я могу согласиться с ответом MikeSW, но, применяя SRP во время моделирования, вы можете получить небольшие классы, что вовсе не проблема.
По словам Грега Янга, доменные события всегда должны выражать то, что пользователь делает с точки зрения бизнеса. Например, если у пользователя есть 2 причины изменить свой номер телефона PhoneNumberChangedи эта информация может быть важной с точки зрения бизнеса, тогда мы должны создать 2 типа событий PhoneNumberMigrated, PhoneNumberCorrected технически хранить одни и те же данные. Это явно нарушает DRY, но это не проблема, потому что SRP может переопределить DRY в этих случаях, как это происходит путем совместного использования агрегатов и их свойств (чаще всего идентификатора агрегата) между несколькими ограниченными контекстами.
В моем примере:
У меня есть что-то простое, например, изменение firstName, secondName и адреса электронной почты на странице профиля.
Мы должны спросить следующее: почему пользователь этого хочет, имеет ли это какое-то значение с точки зрения нашего бизнеса?
- ее учетная запись была украдена (безопасность, а не деловая проблема)
- она переехала на другой адрес электронной почты
- она вышла замуж
- она ненавидела свое прежнее имя
- она дала счет кому-то другому нарочно
- так далее...
Ну, если у нас есть услуги агентства знакомств, то регистрация разводов может иметь деловое значение. Так что, если эта информация действительно важна, то мы должны поместить ее в модель предметной области и создать UserProbablyDivorced событие. Если ни один из них не важен, то мы можем просто сказать, что она просто хотела изменить страницу своего профиля, нам все равно, почему, поэтому я думаю, что в этом случае оба UserProfileChanged или же UserSecondNameChanged события могут быть приемлемыми.
События домена могут быть в соотношении 1:1 и 1:n с командами. По соотношению 1:1 их имена обычно такие же, как и у команд, но в прошедшем времени. Например ChangeUserProfile -> UserProfileChanged, По соотношению 1:n мы обычно разделяем поведение, которое представляет команда, на серию событий меньшего размера.
Итак, подведем итог: решение разработчика домена о том, насколько гранулярными должны быть события в домене, должно определяться, но оно должно явно зависеть от бизнес-перспективы, а не только от моделирования с точки зрения схемы данных. Но я думаю, что это очевидно, потому что мы моделируем бизнес, а не просто структуру данных.