Collection aggregates to support different concurrency models?

[Alexandre Potvin Latreille]

Suppose we have a Course AR in which Student ARs can enroll, but there's a maximum capacity. Would it make sense to have a CourseEnrollments AR that has a capacity and a collection of Enrollment rather than having Course hold a collection of Enrollment?

I'm asking that because in this case, it seems that the concurrency model shall be different for Course and CourseEnrollments. Optimistic concurrency could be used for Course, but pessimistic locking or single thread processing would have to be used for CourseEnrollments because of the expected high contention around enrollments.

What's the proper way of dealing with such problem?

[Kijana Woodard]

I assume this is not the real model, but...

Consider a course should continue accepting enrollments past the cutoff. The extra enrollments become the Waiting List. Then as students make their final course decisions and drop, the waiting list can be used to fill the class. Also, a popular class might get a larger room and extra TAs and raise the enrollment number.

This idea of having a soft cutoff that is dealt with in projections can apply to many domains.

---

From: Alexandre Potvin Latreille
Sent: ‎6/‎20/‎2015 8:37 AM
To: ddd...@googlegroups.com
Subject: [DDD/CQRS] Collection aggregates to support different concurrencymodels?

Suppose we have a Course AR in which Student ARs can enroll, but there's a maximum capacity. Would it make sense to have a CourseEnrollments AR that has a capacity and a collection of Enrollment rather than having Course hold a collection of Enrollment?

I'm asking that because in this case, it seems that the concurrency model shall be different for Course and CourseEnrollments. Optimistic concurrency could be used for Course, but pessimistic locking or single thread processing would have to be used for CourseEnrollments because of the expected high contention around enrollments.

What's the proper way of dealing with such problem?

--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alexandre Potvin Latreille]

@Kijana For the scope of my question, let's consider a waiting list is not an option. The capacity must never be exceeded.

However, even to implement a waiting list, you have the same concurrency issues to solve since you must be able to tell who's waiting and who's not transactionnaly, no? Especially if there are payments involved for non-waiting students...

[Kijana Woodard]

I realize we're not talking about the real domain, so shifting sands and....

Not necessarily. IIRC, there's a registration period, then you find out what you got into, then there's a drop period, final payment is later. Lots of time to deal with consistency. The real world is that people will drop classes.

But that's all irrelevant because you're not actually modeling classes, students, and enrollments.

Make the aggregate handling single threaded and your problem is solved.

---

From: Alexandre Potvin Latreille

Sent: ‎6/‎21/‎2015 9:09 AM
To: ddd...@googlegroups.com
Subject: [DDD/CQRS] Re: Collection aggregates to support different concurrencymodels?

@Kijana For the scope of my question, let's consider a waiting list is not an option. The capacity must never be exceeded.

However, even to implement a waiting list, you have the same concurrency issues to solve since you must be able to tell who's waiting and who's not transactionnaly, no? Especially if there are payments involved for non-waiting students...

--

[Greg Young]

"Make the aggregate handling single threaded and your problem is solved."

until its not then lets talk about the next solution.

--
Studying for the Turing test

[Kijana Woodard]

Yup

---

From: Greg Young
Sent: ‎6/‎21/‎2015 5:11 PM
To: ddd...@googlegroups.com
Subject: Re: [DDD/CQRS] Re: Collection aggregates to support differentconcurrencymodels?

[@yreynhout]

It depends on the problem.

[Alexandre Potvin Latreille]

I was thinking a bit more about this and perhaps the fact that I feel two different locking models need to be used for different parts of the same aggregate is just a symptom of not having properly defined BCs.

The creation and management of Course information could be very CRUD and optimistic locking is probably the proper model to be used for those use cases. However, enrollments and other business operations revolving around enrollments should probably be single-threaded (assuming we need strong consistency).

That leaves me with another question, would the UI talk to both contexts since in order to enroll you need to first be presented with Course information or it's generally better to pick a single context and implement an ACL in it so that the UI deals with a single one? I guess that depends on the kind of integration and availability you need...

If there's no real physical BC segregation, maybe following my initial idea of creating a different aggregate (e.g. CourseEnrollments) is a better idea?