Looking up a user by an attribute on the command side: User a domain service or a query?

[Jack Snow]

I have a event-sourced CRM application where users can be subscribed to newsletters.

We want to implement a command where the customer can unsubscribe or subscribe using a form by entering their email address. As my Customer aggregate is keyed by its ID, from the event-store side, I can only load a customer using their ID.

Therefore, I need to query the read-side from the command to look up their ID and then load the Customer using the ID from the event store.

My read-side is very simple, it is essentially a bunch of SQL queries reaching directly into the database and returning data in their appropriate format.

I am considering 2 ways:

1. Have some service like LookUpCustomerIDByEmail() to find the ID. Then use the ID in CustomerRepository.GetByID(). These would be called in the command handler. Would the LookUpCustomerIDByEmail service be part of the read side or the command side?

2. Implement it as part of the repository: CustomerRepository.GetByEmail(). The first way is to inject the query service into the repository as part of its constructor: new CustomerRepostory(LookUpCustomerIDByEmailService). The second way would be to use it like so: CustomerRepository.GetByEmail(someEmail, LookUpCustomerByEmailService).

Which way would be the best way to do this? Are there better alternatives?

[Dariusz Lenartowicz]

Query for ID at the application service and put it to the command.

[Rickard Öberg]

I have the same situation, and do 1), a read model service to do the
lookup (also handles caching of this data and invalidation based on
new events), which my command handler uses before calling the right
aggregate. The command side (aggregate) should have no idea about what
read models are available, that is why there's a layer before the
aggregate that can tie the read and write together.

/Rickard

> --
> 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.
> Visit this group at https://groups.google.com/group/dddcqrs.
> For more options, visit https://groups.google.com/d/optout.

[Rupesh Kumar Tiwari]

Hi Jack,

I would also go with Application Service using read side lookup service to fetch user id. 

Then Application service will complete execute the command by fetching user by id via repository. 

In this case I believe Query side should own this API. 

According to Hexagonal architecture we should open an port on Query model. 

Let the command side consume this new query. 

Thanks,

Rupesh kumar Tiwari

 

> email to dddcqrs+unsubscribe@googlegroups.com.

> Visit this group at https://groups.google.com/group/dddcqrs.
> For more options, visit https://groups.google.com/d/optout.

--
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+unsubscribe@googlegroups.com.