I’d like to get existing AR from repository or create new if repository does not contains one.
Simple example would be todo lists where a command AddItemToList(listName, itemName) with listName as TodoList identifier adds item to existing list or creates a list if none existed before.
It looks like with current Repository API the best way is try to load AR and catch exception if not found. But this isn’t right… so I was just wondering how this should be implemented.
The best solution is always to make sure the UI’s intent is explicit. Make sure it’s always clear whether you want to create a new entry or update an existing one.
Just curious. How did you come to the conclusion to have a command handler listen for events to find out if an AR already exists? In the thread you linked to, I only mentioned a try-load-otherwise-add approach.
Just curious. How did you come to the conclusion to have a command handler listen for events to find out if an AR already exists? In the thread you linked to, I only mentioned a try-load-otherwise-add approach.
Sorry, my bad. It was just my broken interpretation of “Normally the query model is used to find out whether an aggregate already exists.”.
What if the UI is not involved? I have one aggregate A that needs to know that another separate aggregate B has been setup correctly for it (it’s not that simple, but that’s the basic idea).
I currently have a special “DoesBExist” command which A sends, and it’s handled by a special handler outside the B aggregate, using the injected B repository, and returning a boolean. Based on the return value the A aggregate then sends a “CreateB” or “UpdateB” command. This doesn’t feel very nice.
I think it would be nicer for A to always send a single “CreateOrUpdateB” command. That still needs a custom handler to lookup the correct B, create it if it is missing, and dispatch the command onto it. But at least it is cleaner from A’s side.
‘DoesBExist’ sounds like a question to me. Questions (i.e queries) are by definition not commands.
Query models aren’t only for use by the UI. It is very well possible that a command handler needs to query data to validate an incoming command. It uses a query model to do so.
Normally, aggregates don’t send commands. They just handle them and send out events. Some of these events may trigger another command through an event hander (or more specifically a saga).
I’m not saying CreateOrUpdate commands are always a bad thing. But to me, they come with a distinct odor that cries for investigation. I prefer to invest some time in finding a solution to refactor and make the commands more explicit. I the end, explicit commands make for a better scalable application.