CODEWITHSUNDEEP
transactionsdomain-driven-designdomain-modelaggregateroot
341008
341008

Reputation: 10232

Transactions crossing aggregate boundaries

I have the following domain modelling problem where I seem to end up either crossing consistency boundaries or creating a huge aggregate. Can someone help me break it up?

There are two job types JobA, JobB. JobA is composed of tasks TaskA. JobB is composed of tasks TaskB. JobA and JobB are unrelated. The only thing is common between them is that they both need an equipment resource. I had originally wanted to create 5 aggregate roots which may reference each other - JobA will reference TaskA and so on.

Domain model

I can possibly put a job and its tasks in one aggregate. That comes at an expense of introducing other overhead as tasks themselves are complex creatures. However, the following constraints prevent me from using either model.

  1. A job cannot be marked complete if any task is still incomplete. This check causes transactions to cross aggregate boundaries (e.g., TaskA and JobA).
  2. An equipment cannot be assigned to more than 1 job. This check will span across both job aggregates.
  3. Equipment has to be released before job can be marked complete. This transaction will cross equipment and job aggregates.

Having a single aggregate will put all transactions inside the boundary but that will make the aggregate impossibly large. Is there a different model hidden in all this that I am missing?

Upvotes: 5

Views: 1583

Answers (2)

Vladas Cibulskis
Vladas Cibulskis

Reputation: 201

I know the question is quite old, but I don't see any problems with the architecture you draw and your consistency requirements:

  1. Job has to have a Task list with their statuses. When task completes in it's own transaction, it sends TaskCompleted event/message and then Job picks it up and updates task status internally. This way Job knows if all tasks are completed without checking Task agregate.

  2. Equipment assignment to job must be performed against Equipment aggregate. This will generate EquipmentAssignedToJob event/message that will be consumed by Job aggregate to update it's own state with information that this job is using this equipment. Equipment will know it's own state if it's used or not.

  3. Job complete action will release Equipment. Releasing Equipment from job generates JobFinishedUsingEquipment event/message that can be consumed by Equipment and equipment state will be updated to unused.

Upvotes: 0

Josué Pech
Josué Pech

Reputation: 194

I think the best solution could be using eventual consistency.

When I have doubts about designing agreggates I always take a look to Effective Agreggate Design by Vaughn Vernon.

Upvotes: 1

Related Questions