Building a Reusable Toolset: Where Aspects Actually Live
Every aspect this series has introduced eventually needs somewhere real to sit.
A basic specification maintainer, built in roughly this order. JSON Schema validation first, nothing clever, just a way to check a submitted specification is structurally valid before anything else happens to it. Optimistic version control next, with full branching, parallel version lines, deliberately deferred to its own module rather than solved upfront. A workflow layer after that, with graduated trust, some changes auto-approve, others require sign-off, and deciding which is which will itself be a design decision the tool has to encode. Content constraints layered on last, once structure and process are sound. A plain database underneath the whole thing, because the point was never going to be the storage technology.
That order is the lesson, before a line of it exists. Structure before process. Process before content. And the genuinely hard problem, branching, isolated deliberately rather than solved inline with everything else.
Every idea in this series will eventually meet this same question. Stored how, exactly.
Assemble, Don’t Start From Zero
None of this needs building entirely bespoke, either. A schema validator already exists, several of them, mature and well tested. A workflow or approval engine already exists in most ecosystems, ready to be pointed at a new problem. The work actually worth doing by hand will be the thin layer gluing existing tools together around the specific shape this framework needs, not reinventing what already works well elsewhere. The same composition-over-consolidation principle from earlier in this series, applied here to building the toolset itself, not just to the systems it manages.
Success will come the same way, incrementally. Schema validation working on its own will already be useful, before version control exists at all. Version control working will be useful before the workflow layer exists. Nothing needs to wait for the whole toolset to be complete before any single piece of it starts paying for itself.
Two Consumption Patterns, Two Different Needs
A governance tool wants the whole evidence bundle from Providence, read rarely, read in full, every detail intact. A runtime resolver wants one narrow question answered fast and often, is this coordinate valid right now. Forcing both through the same storage shape means one of them always pays a cost it didn’t need to.
The Core Move: Extraction, Not Duplication
The document store holds the aspect, whole. A hybrid table sitting alongside it holds only the core attributes worth indexing, extracted for speed. The table isn’t a second source of truth. It’s a performance-oriented projection of the one that already exists, a lens, in the fuller sense this series already gave that word, applied here to storage instead of transport.
One Wrapper, Whatever the Transport
The envelope structure this series introduced doesn’t change shape depending on how it arrived. A message published to Kafka, delivered over gRPC, or dropped in an SQS queue all carry the same header-plus-aspects wrapper. The tooling reading it doesn’t need a different deserialiser for each protocol, only a different way of receiving the bytes. Once received, it’s the same structure whether it came in over REST, gRPC, Kafka, or SQS.
Get Stephen James Price’s stories in your inbox
Join Medium for free to get updates from this writer.
This is where an earlier line in this series actually pays off. A message in flight and a record at rest were said to share more structure than the words suggested. Here’s the practical version. The tooling that reads an aspect out of a stored document and the tooling that reads an aspect out of an inbound message can be, largely, the same tooling. The wrapper doesn’t know or care whether it just crossed a network or has been sitting in a table for six months.
What Building This Will Surface
Back to the specification maintainer. Schema validation alone won’t be enough on its own, it will catch structural problems but say nothing about whether a value makes sense. Deferring branching isn’t a shortcut to regret later, it’s the right call, because getting the simple, unbranched case solid first will make the harder case tractable, instead of tangled up with everything else from day one. The workflow layer is where the real design work will live, not in the approval mechanism itself, but in deciding, deliberately, which changes deserve a human’s attention and which don’t.
None of this is obvious from the outline alone. It will only become visible once an actual specification maintainer is sitting in front of an actual database.
Why There’s No Single Right Answer
A tool built for governance and a tool built for runtime resolution are not the same tool, and shouldn’t be forced to share one storage shape just because they’re reading the same aspect. The framework’s job isn’t to mandate a technology. It’s to mandate that whatever technology gets chosen still respects identity, versioning, and aspect boundaries, so a document store and a hybrid table can sit side by side, both correct, both honest about what they are.
Truly Decoupled Services
Put transport and storage decoupling together and something bigger falls out. A service no longer needs to be a fixed thing a caller hardcodes against. It can be an entry in the catalogue, its specification, its current implementation, and the coordinate to reach it, all stored as data rather than assumed knowledge sitting in someone’s client code.
This is where the catalogue stops being a nice-to-have index and becomes load-bearing. Available assets, and the services that implement their APIs, are managed the same way, as catalogued, addressable, versioned records. Swapping an implementation, adding a second one behind the same specification, retiring an old version, none of that requires touching every caller. It requires updating an entry in the catalogue. Specification and implementation, managed as data, are what make the rest of this series’ decoupling actually deliverable, not just architecturally pleasant.
Close
This is where the rest of the series lands. Catalogues, specifications, envelopes, evidence, cost reports, all of it eventually gets written to disk, or sent over a wire, by something. A reusable toolset is what happens when that last step gets the same discipline as everything built on top of it, rather than being treated as an implementation detail nobody thought through. One piece remains after this, pulling the governance threads running through the whole series together into a close.
Building the toolset itself, properly, is a bigger job than one article can hold. That’s where this series ends and a follow-up one begins, realising the system this series has spent its length describing.
