Recently I faced a problem while testing application and just wanted
to get some advice on how to change my domain or to test
appropriately.
Let's say there's yet another e-shop application. Customer (aggregate
root) own one or more ShoppingBasket (entity). Of all available
ShoppingBaskets there is one selected as active at the time. Customer
can also create a new basket, set any of the available as the active
one, etc.
What I would do in this situation I would create a unique identifier
for each basket in order to be able to refer to it. However, this
would mean that after creating a new ShoppingBasket a
ShoppingBasketCreatedEvent would be fired holding a random identifier
and I'm not sure how to test this using axon fixture. Can a Matchers
be used in this situation or the domain should be designed
differently?
Include the identifier in the CreateBasket command. Don't generate it
inside your command handler.
I do this with all my identifiers. This way the client (the test in
this case) knows what I'd to look for.
Per’s solution is a very viable one. Keep in mind that an aggregate boundary (as defined in DDD) also poses a limitation on the references that one may hold to entities inside the aggregate. One may exclusively hold a reference to an aggregate root. A shopping basket’s ID can only be unique within the context of an aggregate. You should always refer to that shopping basket via the aggregate root.
We have similar cases in some of our own projects, and simply used a sequential identifier for the entities. In your test cases, you know howmany entities you create, and what their identifiers should be.
In you scenario, if a user creates a basket with a certain name, you could even use that name to refer to a specific basket. In contrast to the Aggregate Identifier, an entity’s identifier can safely change over time.