lngr
commented
9 years ago Yes, but actually this is by design and documented:
The Repository interface provided by JCommonDomain requires that
aggregates queried do exist, see the javadoc on ofIdentity() in
https://github.com/JEEventStore/JCommonDomain/blob/master/common/src/main/java/org/jeecqrs/common/domain/model/Repository.java.
So, querying for an aggregate that does not exist is considered a programming error.
To avoid this, one can check whether the aggregate root exists before loading the AR. We usually do this on a case by case basis (usually the command handler would know whether the command can be run against non-existing aggregate roots and how to handle both cases).
The rationale behind this contract on ofIdentity()is that a NotFoundException on ofIdentity() would induce lots of try ... catch boilerplate code in every single consumer of the Repository interface, while in most cases that additional check is simply not required (commands are seldom issued against
non-existing aggregate roots). Thus, we prefer to use an additional exists() in the rare cases where commands can be sent against non-existing aggregate roots.
This is a somewhat personal preference, of course. However, note that JEEventStore throws a checked exception org.jeeventstore.StreamNotFoundException when the stream id does
not exist (see above stacktrace). This can of course be propagated to the repository accordingly. Thus, when a NotFoundException is desired, it should be straight-forward to implement as custom repository based on the JCommonDomain implementation.
By the way, both JEEventStore and JEECQRS additionally provide a completely synchronous implementation of command bus, sagas and event handlers, such that a client can be sure all changes have been committed to the database when the commandBus.send() returns. We usually use the synchronous implementations for small projects with few users, and the asynchronous model for "web scale" applications with many concurrent users.
heutelbeck
Context: A multi tenant aggregate root and its repository with a create command.
If I do a
and directly follow this with:
Due to the asynchronous nature of the process, the aggregate has not been created yet. The resulting exceptions cause the commandBus to break (maybe other things as well. I did not check beyond that) and the command is never delivered. This must not happen, but result in a graceful exception handling and should result in something like a NotFoundException.