Подтвердить что ты не робот

Соглашение об именах для команд и событий

Я просто попадаю в архитектуры, управляемые событиями, и хотел бы знать, что означает соглашение об именах команд и событиях. Я знаю это много: Команды должны быть в форме DoSomething, а события должны быть в форме SomethingHappened. Что мне нужно прояснить, так это если мне нужно добавить слово "Command" к моим командам и "Событие" к моим событиям, например. DoSomethingCommand, а не только DoSomething и SomethingHappenedEvent, а не просто SomethingHappened. Я также хотел бы знать, какое обоснование стоит за принятой общиной конвенцией. Спасибо!

4b9b3361

ОТВЕТЫ

Ответ 1

Суффиксы Command и Event являются необязательными и относятся к предпочтениям. Я предпочитаю их опускать и пытаюсь сделать намерение очевидным только из названия. Самый важный аспект команд и событий именования - убедиться, что они отражают бизнес-домен больше, чем технический домен. Много раз такие термины, как "Создать", "Обновить", "Добавить", "Изменить", слишком технические и имеют меньший смысл в бизнес-области. Например, вместо того, чтобы говорить UpdateCustomerAddress, вы можете сказать RelocateCustomer, который может иметь более широкий бизнес-контекст.

Ответ 2

Мое соглашение зависит от пространств имен, и я имею в виду, что я никогда не использую суффикс Event или Command.

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

Пример:

// Commands
MyApp.Messages.Commands.Customers.Create
MyApp.Messages.Commands.Orders.Create
MyApp.Messages.Commands.Orders.AddProduct

// Events
MyApp.Messages.Events.Customers.Created
MyApp.Messages.Events.Orders.Created
MyApp.Messages.Events.Orders.ProductAdded

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

Ответ 3

Добавление команды и события будет избыточной информацией, если команды или события yor правильно названы. Это будет шум, который сделает ваш код менее читаемым. Помните венгерскую нотацию? Большинство программистов (я знаю) больше не используют его.

Ответ 4

Команды и события образуют язык для вашего приложения... API. Использование терминов, таких как "команда" и "событие", возможно, полезно для определений на системном уровне, где технические термины существенно смешиваются с целью объекта, но если вы имеете дело с определениями поведения домена, то отбросьте системную/техническую терминологию и выступать за деловые разговоры. Это сделает ваш код более естественным и уменьшит печатание. Я начал с придатков "Command" / "Event", но понял, что это пустая трата времени и отвлекла меня от популяризированного DDD Ubiquitous Language. НТН, Mike

Ответ 5

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

  • UserRegistered
  • AccountActivated
  • ReplyPosted

Команды - это то, что вы хотели бы сделать. Поэтому создайте имена, которые иллюстрируют это:

  • CreateUser
  • UppgradeUserAccount

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

То есть я создаю пространство имен для каждого корневого агрегата и помещаю под него все (определение репозитория, события, команды).

  • MyApp.Core.Users
  • MyApp.Core.Posts

и др.