Hi,
Recently the The aggregate is dead. Long live the aggregate! video made a bunch of waves in the #event-sourcing channel on the DDD discord, and I want to take a moment to talk about solving some of the challenges outlined there with EventStore.
First, I want to credit the authors for bringing to light that current ES/CQRS storages can boost the teams out there by covering more challenging areas that are pure technical concerns and solving, which were historically associated with tradeoffs.
That is what technology tools are about and should strive for.
First challenge: set validations on a single event stream and across a couple of aggregate streams.
Set validations on an event stream, e.g. verifying that less than a hundred students subscribed to a given course is trivially solvable by putting an SQL table with a relevant constraint in front of the aggregate.
Cross-event stream set validation, e.g. simultaneously checking that the student about to subscribe to the course is subscribed to less than ten courses, might be that trivial anymore.
I reckon the solution proposed in the video is not even on the horizon, and I wonder if it would be possible to add constraints on user-defined projections.
That is, to solve the former problem, we can build two projections:
- the number of students per course
- the number of courses per student
And then define constraints, either dynamically, when appending events or on those projections (sigh) to say something like:
CONSTRAINT HAVE MAX(students_per_course < 100) AND HAVE MAX(courses_per_student < 10)
WHERE
students_per_course.course_id = ${course.id} AND courses_per_student.student_id = ${student.id}
I hope the idea above will drown in rightful criticism because I’m not a fan of SQL, to say the least, but offloading those problems on the storage does bring significant benefits.
Cheers.