I am looking for design insights anyone can offer regarding the classic n-to-many relationship problem.
Trying to keep this as brief as possible, imagine a scenario where we have a Job management system, each job consists of a work program of one or more steps, each step can be performed by a different team and at the time of creation, the team that will perform the work program step is unknown. At some point a team is chosen to perform a work program step and this is known as a work order.
Within the domain we have two aggregates, the Job and the Team, where the work-order provides the relationship between the job and the team.
The job has a permanent record of all work-orders, where each work-order has a natural start and end. There can only be a single ‘active’ work-order at any given time and this invariant is enforced in the job aggregate.
A team can only be working on a single work-order at any given time and, again, this invariant is enforced through the team aggregate, the teams work-order history is saved via projection.
The duration of a work order can span anything from a few minutes to multiple days and can progress through various state changes. This is managed via a saga which coordinates updates between the Job and the Team aggregates.
At the time a work-order is created, it may not be sent to the team immediately, and the state of the job may sometimes change before the work order is ‘released’ to the team doing the work.
The problem I am struggling with is; I don’t particularly want to mirror the Job state in the saga but I somehow need to be able to account for state changes between the creation time of the saga and the time the work order is released to the team.
So, at the point of releasing the work order to the team do I:-
Send a command to the Job aggregate updating the work-order status to ‘released’ and have the job aggregate reflect its current state in the corresponding event, then have the saga use this to have the Teams work-order item updated and then delivered?
Inject a service into the saga and use it to query the job aggregates state
Do something else?
My gut says I should be using option 1 above but I am wondering if there is a better approach?
Many thanks, Andy.