Доступ к сеансу в объекте домена

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

class Order { 
  setNameBy(newname, User user) {
    applyChange(new OrderRenamed(user.id, newname));
  }
  :
}

Так как большинство наших методов такие и все они вызываются вот так

setNameBy("a new name", SessionContext.currentUser)

мы обдумывали доступ к SessionContext внутри объекта домена. то есть:

setNameBy(newname, User user) {
  applyChange(new OrderRenamed(user.id, newname));
}

становится

setName(newname) {
  applyChange(new OrderRenamed(SessionContext.currenUser.id, newname));
}

Лично я предпочитаю более позднюю сигнатуру метода, поскольку она кажется более естественной, с другой стороны, доступ к SessionContext внутри объекта Domain кажется немного запутанным.

Итак, как вам лучше всего обрабатывать данные сеанса, подобные этому, в приложениях DDD/CQRS? Можно ли получить доступ к SessionContext в объектах домена или мне следует использовать другие методы, такие как обогащение событий, чтобы добавить эту информацию к событиям, исходящим из домена?


cqrs event-sourcing domain-driven-design
person Lars Tackmann    schedule 09.04.2012    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Если отслеживание пользователя, инициировавшего изменение, происходит часто, тогда SessionContext становится неотъемлемой частью решения и, следовательно, IMO является путем наименьшего сопротивления (достаточно хорошее решение). Возможно, переформулировка UserContext сделает его менее похожим на «грязную» техническую связку? :)

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

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

Оба решения являются достаточно хорошими решениями IMO, поэтому в основном это вопрос того, где вы хотите подключиться к SessionContext.

person Jeppe Cramon    schedule 11.04.2012

arrow_upward
2
arrow_downward

Я предпочитаю, чтобы мои модели предметной области были полностью игнорированы внешними деталями. Если вашим объектам домена требуется идентификатор пользователя для обеспечения соблюдения бизнес-правил, я бы использовал ваш текущий подход и отправил пользователя в качестве аргумента. Если вам нужен только идентификатор пользователя для целей отслеживания/аудита, вы можете дополнить событие.

person Dennis Traub    schedule 11.04.2012