Hi,
I’m designing an axon application that involves the creation of a process definition.
Each process can have some sub processes, each sub process can have himself other subprocess and/or tasks, and for each level of the process we can assign work to do and permissions.
My model is composed of a ProcessDefinition aggregate with some aggregate members for sub processes/tasks and work/permission.
For the query side I have a table defining all the process activities (process, sub processes, tasks) including a link towards the parent activity to be able to reconstruct the tree of activities.
We use some kind of inheritance for all data defined. For instance it’s possible to set a default “task outcome” at the level of the process that will define the default outcome for all the tasks unless a more specific task outcome is defined at the level of the sub process or the task.
My question is, how should this case be handled DDD wise? For instance when a command SetTaskOutcome is sent at the level of the process, should I only apply a TaskOutcomeSet event for the process and deal with the inheritance logic in my read model or should I do all this business logic in my aggregate sending a TaskOutcomeSet event for each task of the hierarchy?
This aspect is not so clear to me.
I hope my question is clear at least 
Thanks a lot,
Thomas
Hi Thomas,
There really isn’t a yes or no answer in this case. DDD neither necessitates the requirement to have fine grained or coarse grained events at all.
What should be the driving force to go one way or another, is what is valuable for the business.
Is there a real need to have all these fine grained TaskOutcomeSet events, so that it is specific to anybody tuning into the event stream?
Then that would be the way to go, knowing a lot of events might be published throughout the hierarchy.
Is it however an obstruction to publish so many events, and a single fat TaskOutcomeSet will do the trick?
Then that would be the solution to take, knowing some domain logic resides in the event handlers to pull this event apart.
Of course there is a rule of thumb though. Typically I would suggest to keep your domain logic in your command model at all times, with exceptions sometimes popping up for very specific scenarios.
Even these exceptions can eventually become actual domain events as soon as more handlers turn out to be interested in them. That’s just the nature of an evolving application of course.
Giving the scenario you have sketched, my gut would tell me the hierarchy definition logic belongs in the command model.
But, I am far from a domain expert on your application, so I might be making the wrong assumption here.
So, in short, the answer would be it depends.
And personally, I would discuss with your team/business whether there is value in having fine grained events.
That’s my two cents.
Cheers,
Steven
PS. It is important to note that this mailing list will be discontinued as specified in this thread.
The thread also specifies where to look further for help when it comes to Axon as soon as this mailing list is closed.