ACID, SOLID, and Design Patterns: A Complete Software Design Reference

Part 25 of 26 · ~2 min

How These Three Layers Connect

The clearest single moment where every layer of this reference meets happens the instant a coordinator's assignment actually gets saved. Trace it all the way down. EfShiftRepository is Repository, a Structural pattern, standing behind the IShiftRepository interface — and reaching for an interface there instead of the concrete EF Core type is Dependency Inversion doing its job, which is the only reason ShiftAssignmentService could be unit tested earlier with a fake standing in for a real database.

Follow what happens when that call actually reaches the database. It runs inside a transaction, and Atomicity is what makes an interrupted process incapable of leaving a shift assigned to a volunteer with no matching hour-ledger entry, or the reverse — the exact failure mode an unwrapped write would produce, and the same guarantee that kept a seat from ending up half-sold on the hold desk back in Part 1. Isolation, set appropriately, is what stops two coordinators from both successfully claiming the very last open slot on a popular shift. The application code never implements either guarantee from scratch — its entire job is to invoke them the right way, exactly like BookSeatAsync did back at the start of this reference.

Zoom out and the layering is the whole argument of this reference in miniature: a pattern is just a name for a recurring shape in code, a principle is the reason that particular shape earns its place over whatever felt easiest in the moment, and a transactional guarantee is the thing underneath both of them that neither the pattern nor the principle had to build — the database was always going to hold up its end, whether what sat on top of it was a box office or a volunteer roster.