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

Question

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

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 внутри объекта домена.

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

Answer 1

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

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

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

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

Answer 2

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