How to get list of aggregates using JOliviers's CommonDomain and EventStore?

Question

The repository in the CommonDomain only exposes the "GetById()". So what to do if my Handler needs a list of Customers for example?

Answer 1

On face value of your question, if you needed to perform operations on multiple aggregates, you would just provide the ID's of each aggregate in your command (which the client would obtain from the query side), then you get each aggregate from the repository.

However, looking at one of your comments in response to another answer I see what you are actually referring to is set based validation.

This very question has raised quite a lot debate about how to do this, and Greg Young has written an blog post on it.

The classic question is 'how do I check that the username hasn't already been used when processing my 'CreateUserCommand'. I believe the suggested approach is to assume that the client has already done this check by asking the query side before issuing the command. When the user aggregate is created the UserCreatedEvent will be raised and handled by the query side. Here, the insert query will fail (either because of a check or unique constraint in the DB), and a compensating command would be issued, which would delete the newly created aggregate and perhaps email the user telling them the username is already taken.

The main point is, you assume that the client has done the check. I know this is approach is difficult to grasp at first - but it's the nature of eventual consistency.

Also you might want to read this other question which is similar, and contains some wise words from Udi Dahan.

Answer 2

In the classic event sourcing model, queries like get all customers would be carried out by a separate query handler which listens to all events in the domain and builds a query model to satisfy the relevant questions.

If you need to query customers by last name, for instance, you could listen to all customer created and customer name change events and just update one table of last-name to customer-id pairs. You could hold other information relevant to the UI that is showing the data, or you could simply hold IDs and go to the repository for the relevant customers in order to work further with them.

Answer 3

You don't need list of customers in your handler. Each aggregate MUST be processed in its own transaction. If you want to show this list to user - just build appropriate view.

Answer 4

Your command needs to contain the id of the aggregate root it should operate on. This id will be looked up by the client sending the command using a view in your readmodel. This view will be populated with data from the events that your AR emits.