Explicitely pass the Actor/User/[InsertBusinessRoleHere] to aggregate methods?

[Alexandre Potvin Latreille]

Should I always pass the Actor/User/[InsertBusinessRoleHere] to aggregate methods or I should just rely on a generic mechanism that adds this information as metadata on the stored events (e.g. userId)? Most DDD examples that I've seen do not bother to pass to the domain who issued the command.

For instance, a process where we may correct a Reminder's email address:

1. public void correctEmailAddress(Corrector corrector, ValidEmailAddress emailAddress);

2. public void correctEmailAddress(UserId userId, ValidEmailAddress emailAddress);

3. public void correctEmailAddress(ValidEmailAddress emailAddress); //Just attach userId on the event metadata.

For which one would you guys go?

 

[Chris Martin]

I usually wrap commands in a context object that holds that sort of data. It is then persisted to the event metadata. Right or wrong, I have no clue. It works for me.

--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Javier Novo Rodríguez]

We add the userId to the command message and store it in the event metadata along the commandId and other information such as the host from that sent the message. This kind of moves some very specific concerns to the infrastructure - which we might eventually regret - but it is quite simple and works for us right now.

[Peter Hageus]

We have a context object passed to the commandhandler, with user id among other things. It’s also copied to event metadata by the infrastructure.

 

/Peter

 

Från: ddd...@googlegroups.com [mailto:ddd...@googlegroups.com] För Javier Novo Rodríguez
Skickat: den 22 september 2016 11:51
Till: DDD/CQRS <ddd...@googlegroups.com>
Ämne: Re: [DDD/CQRS] Explicitely pass the Actor/User/[InsertBusinessRoleHere] to aggregate methods?

 

We add the userId to the command message and store it in the event metadata along the commandId and other information such as the host from that sent the message. This kind of moves some very specific concerns to the infrastructure - which we might eventually regret - but it is quite simple and works for us right now.

On Tuesday, September 20, 2016 at 10:30:32 PM UTC+2, Chris Martin wrote:

I usually wrap commands in a context object that holds that sort of data. It is then persisted to the event metadata.   Right or wrong, I have no clue. It works for me.

 

 

On Tue, Sep 20, 2016 1:22 PM, Alexandre Potvin Latreille alexandre.pot...@gmail.com wrote:

Should I always pass the Actor/User/[InsertBusinessRoleHere] to aggregate methods or I should just rely on a generic mechanism that adds this information as metadata on the stored events (e.g. userId)? Most DDD examples that I've seen do not bother to pass to the domain who issued the command.

 

For instance, a process where we may correct a Reminder's email address:

 

1. public void correctEmailAddress(Corrector corrector, ValidEmailAddress emailAddress);

2. public void correctEmailAddress(UserId userId, ValidEmailAddress emailAddress);

3. public void correctEmailAddress(ValidEmailAddress emailAddress); //Just attach userId on the event metadata.

 

For which one would you guys go?

 

 

--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.