Я новичок в Event Sourcing, и я подумываю использовать его для промышленного применения для отслеживания событий, происходящих на производственном объекте.
Поскольку книга записей - это само производственное предприятие, а не система, иКроме того, поскольку не все автоматизировано, работники должны будут сообщать в определенный момент времени (зарегистрированное время), что они сделали в другой момент времени (эффективное время).Поэтому я буду использовать такие события, как: TankFilledRecorded, TankOutputConnectedToPipeInputRecorded, ContainerMovedToFacilityAreaRecorded и т. Д., Где эти события относятся, например, к таким объектам, как танк, труба или зона объекта.Эти события будут иметь как записанное время, так и эффективное время.Обратите внимание, что не существует процесса представления или утверждения для записи, которая будет считаться законной.
Проект, управляемый доменом (DDD), поощряет разработку событий, которые отражают то, что происходит в домене (как те, что указаны выше).Тем не менее, в моей области меня не волнует, как появился танк, труба или территория объекта.Мне просто нужно знать, что что-то существует с определенного момента времени, и мне также нужно знать, не существует ли этого после определенного момента времени.Основной целью программного обеспечения является отслеживание жидкостей и порошков, протекающих в цепи, состоящей из этих труб, резервуаров и других компонентов.Это не система управления активами, и она не должна стать ею.
Следовательно, каков будет правильный метод DDD для разработки события, отражающего тот факт, что в производстве есть резервуар, труба или участоксредство?
Это тонкий вопрос, но язык важен, особенно в DDD.
Вот что я придумал:
1 EntityExistenceAcknowledgmentRecorded
TankExistenceAcknowledgmentRecorded
PipeExistenceAcknowledgmentRecorded
FacilityAreaExistenceAcknowledgmentRecorded
TankDisappearanceAcknowledgmentRecorded
PipeDisappearanceAcknowledgmentRecorded
FacilityAreaDisappearanceAcknowledgmentRecorded
Кажется ужасным использовать это на вездесущем языке.Я не вижу себя говорящим в этих терминах или предоставляющим пользовательский интерфейс с таким словарным запасом.Но это точно отражает то, что происходит.
2 EntityRegistered
TankRegistered
PipeRegistered
FacilityAreaRegistered
TankUnregistered
PipeUnregistered
FacilityAreaUnregistered
Кажется, что это намного проще, и это также имеет смысл, за исключением одной вещи.«Зарегистрированный» передает существование представления субъекта в системе с немедленным вступлением в силу , без возможности сказать сейчас, что субъект существовал 2 дня назад.Подумайте о событии UserRegistered на веб-сайте, которое указывало бы на то, что пользователь «существовал» 10 дней назад.Что бы это даже значило?
События - это факты, и вы не можете изменить прошлое.Однако мне нужен способ, чтобы мои пользователи могли сделать недействительной запись, в которой они допустили ошибку, такую как опечатка.Теперь они могут записать, что они признали существование области объекта неделю назад и могли бы понять позже, чем было что-то не так, например, опечатка в имени объекта.Они сделали бы запись недействительной и создали бы новую.Но аннулировать что-то, что было «зарегистрировано», звучит неправильно.
3 Продолжайте искать
Попытайтесь копать больше в домене (штурм событий) и найдите реальные события, которые принесли сущностидаже если эти события бесполезны в проблеме, которую необходимо решить.
TankBuiltRecorded
PipeBuiltRecorded, PipeDeliveredRecorded
FacilityArea<something_meaningful>Recorded
TankDestroyedRecorded, TankDecommissionedRecorded
PipeDecommissionedRecorded
FacilityArea<something_meaningful>Recorded