5

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?

341008
  • 9,862
  • 11
  • 52
  • 84
  • 1
    Some rules can't be made strongly consistent in a practical way and will have to be made eventually consistent. – plalx Jul 06 '15 at 12:45

2 Answers2

1

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.

Josué Pech
  • 194
  • 5
  • That's the one I have been using too :). But couldn't get to a solution from there. Maybe I am missing something. I thought about eventual consistency but the problem is that a person is not allowed to move to a new job till he finishes the current one. And the job is part of a workflow so all tasks _have_ to be complete when it is marked complete - cannot allow them to happen out of sync at any point. – 341008 Jul 12 '15 at 16:21
  • I think you are missing nothing. I think it would depend on business perspective, if they tolerate the jobs to be out of sync for small amount of time or not. – Josué Pech Jul 13 '15 at 15:57
  • @341008 curious what you ended up doing here and why. I've had this situation go both ways. – Jordan Jun 27 '19 at 13:15
0

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.

Vladas Cibulskis
  • 161
  • 2
  • 7