Clever Geek Handbook

Transactions that cross aggregate boundaries

I have the following domain modeling problem where I seem to end up with either border crossing borders or creating a huge aggregate. Can anyone help me figure it out?

There are two types of work JobA

, JobB

. JobA

consists of tasks TaskA

. JobB

consists of tasks TaskB

. JobA

and are JobB

not related. The only thing in between is that they both need a hardware resource. I originally wanted to create 5 aggregate roots that can refer to each other - JobA

will refer to TaskA

, etc.

Domain model

I can put a task and its tasks in one unit. This comes at the cost of introducing other overheads as the tasks themselves are complex creatures. However, the following restrictions prevent me from using any model.

  • A task cannot be marked complete if a task has not been completed yet. This check forces transactions to cross common boundaries (for example, TaskA

    and JobA

    ).
  • Equipment cannot be assigned to more than one job. This check will cover both task aggregates.
  • The equipment must be released before completion of the work. This transaction will traverse equipment and job aggregates.

Having a single aggregate will put all transactions inside the border, but it will make the aggregate impossible to large. Is there another model in all this that I am missing?

+3


source to share


2 answers


I think the best solution might be to use the final consistency.



When I am in doubt about designing aggregated sentences, I always look at Effective Agreggate Design by Vaughn Vernon .

+1


source


I know the question is quite old, but I see no problem with the architecture you are drawing and your consistency requirements:



  • The task must have a list of tasks with statuses. When the task completes its own transaction, it dispatches a TaskCompleted event / message and then the Job fetches it and updates the status of the task internally. This way, Job knows that all tasks have completed without checking the Task agregate.

  • The assignment of the equipment to the task must be performed against the equipment assembly. This will result in an EquipmentAssignedToJob event / message that will be consumed by the Job's aggregate to update its own state with the information that this job is using this equipment. The equipment will know its own state if it is in use or not.

  • The shutdown will be released. Dismissing equipment from a job generates a JobFinishedUsingEquipment event / message that can be used by equipment and equipment will be refreshed to unused.

0


source






More articles:


All Articles