The Ecosystem Around the Chassis

Thirty chapters ago — twenty-two in the parent series, seven so far in this one — I introduced Convey as “the open-source .NET microservices toolkit from the DevMentors ecosystem” and then, for thirty chapters, wrote about the toolkit and almost never about the ecosystem. That word was doing a lot of unexamined work. Convey did not fall out of the sky as thirty-two well-factored packages; it was extracted — from real teaching systems, by people who had built the same plumbing too many times, alongside sibling projects that solve the problems a chassis deliberately doesn't. You cannot fully evaluate the toolkit without knowing what it was extracted from and what it delegates outward. So the last missing chapter is the map.

Everything here is open source by the DevMentors team (devmentors.io) and its authors — I am, as ever throughout both series, a reader and user drawing the map, not the cartographer who made the territory.

DShop: the ancestor

Before Convey there was DNC-DShop — the sample system for DevMentors' “.NET Core microservices” course era. A dozen repositories: an API gateway, services for customers, products, orders, identity, notifications, operations, storage, a shared DNC-DShop.Common library binding them together.

That Common library is the genetically interesting part. Open it next to Convey and you are looking at the before picture of everything the parent series covered: the RabbitMQ conventions, the Mongo helpers, the JWT handling, the service registration — all present, but as one shared library that every DShop service references wholesale. It is exactly the artifact part 1 described teams accreting by accident: the copy-paste bootstrap, graduated into a monolithic common package. And it has the failure mode all Common libraries have — every service takes all of it, version bumps are fleet-wide events, and the library grows a gravitational pull that attracts whatever nobody knew where to put.

Convey is what it looks like when someone takes that lesson seriously: Common exploded into thirty-two packages you adopt individually, each with the section-per-package contract this series has been reading. The repo-of-repos packaging from last chapter isn't an eccentricity — it is the anti-Common design position, enforced at the NuGet layer. If you ever need to argue for splitting your own shared library, this pair of codebases is the argument, in public, with commit history.

Pacco: the proof

If Conveyor — the three-service sample from chapter one — is the classroom demo, Pacco is the dissertation. It is DevMentors' full reference system: an exclusive parcel-delivery domain, built as a constellation of repositories — availability, customers, deliveries, identity, orders, parcels, pricing, vehicles, an order-maker, an operations service, an API gateway — every one composed on Convey, orchestrated by compose files and service manifests in an umbrella repo.

Three things make Pacco worth your reading time after thirty chapters of Convey source.

It shows the chassis under a real architecture. Conveyor's services are deliberately flat — a handler, a repository, done. Pacco's services carry actual internal architecture where the domain warrants it: clean-architecture layering, DDD tactical patterns, domain events distinct from integration events. The chassis question the samples can't answer — where do Convey's seams sit when there are four layers instead of one? — Pacco answers per service, and not uniformly, which is itself the honest answer.

The Operations service closes a loop both my series left open. Pacco.Services.Operations is a service whose only job is tracking the progress of distributed operations — subscribing to the fleet's events and answering “what happened to my request?” for clients facing an asynchronous system. Part 11 covered commands and events on the wire and part 12 made delivery reliable, but neither answered the UX question every event-driven system meets in week two: the HTTP caller got a 202 — then what? Operations is the pattern answer (a saga-shaped read model over correlation ids), and it is built from the same SubscribeEvent<T> primitives this series read.

It is the migration target for the copy-paste onboarding from last chapter: when a team outgrows the Conveyor samples, the next known-good service to imitate is a Pacco service, not a bigger Conveyor.

The delegations: Ntrada, Chronicle, Pactify

The sharpest way to understand a toolkit's philosophy is to list what it refuses to do. Convey has no API gateway package, no saga package, no testing package — and the ecosystem answers all three, as separate projects rather than more chassis packages.

Ntrada (from entrada, entrance) is the API gateway: configuration-driven — routes, forwarding, auth, transformations declared in YAML — with the explicit goal of requiring “no coding whatsoever,” and extensions for the same infrastructure Convey speaks (RabbitMQ so a gateway route can publish a message instead of forwarding HTTP, tracing, and friends). Note the philosophical consistency: Convey turned service plumbing into config sections; Ntrada turns the gateway into a config file. Same bet — infrastructure is declaration, not code — placed at the next tier up. Pacco runs its gateway this way, and the moment you see a YAML route that dispatches straight onto RabbitMQ, the dispatcher-endpoints idea from the parent series clicks into place as one instance of a pattern the whole ecosystem repeats.

Chronicle is the saga/process-manager library — long-lived, multi-service transactions with state, correlation and compensation. Convey's messaging gives you at-least-once events and an inbox; it deliberately does not give you “book the vehicle, reserve availability, charge the customer, undo everything if step three fails.” Chronicle is that layer, and its existence as a separate library is the design statement: workflow is application architecture, not chassis plumbing. (MassTransit and NServiceBus bundle sagas into the bus; the DevMentors stack unbundles them. Having run both philosophies, I have come to prefer the unbundled one — sagas change for domain reasons, buses change for infrastructure reasons, and separate libraries let them.)

Pactify is the contract-testing tool — consumer-driven pacts, PACT.io-inspired, publisher-verified — the rigorous version of the /_contracts snapshot idea from the testing chapter. In a conventions-based system where class names are the wire protocol, contract tests are not optional hygiene; the ecosystem shipping its own tool for them tells you the authors knew it.

Around these sit the rest of the constellation — Trill and other course systems exploring event sourcing and different slices of the same philosophy — but the reading order above is the load-bearing one.

Closing both series

Thirty chapters, one toolkit, and the shape of the whole thing is finally visible. The parent series read the chassis: a builder, a discipline, thirty-two packages that turned bootstrap boilerplate into composition. This series read everything around the chassis: the samples that teach it, the config that activates it, the odd package in the corner, the outbox trade-offs, the operational bill, the test suite, the onboarding path, and now the ecosystem it belongs to.

If I compress thirty chapters into one takeaway, it is this: Convey's real product was never the packages — it was the consistency. One pattern (Add*, a section, a Use*), applied uniformly across every concern a distributed .NET system has, at a size one person can actually read. The platform has since absorbed many of the individual solutions — the retrospective tallied that honestly — but the discipline is not absorbable. It has to be chosen, and re-chosen, one package at a time. That is why this codebase is still my recommended reading for anyone building shared platform libraries in .NET, years after its era: not as a dependency to adopt, but as the clearest worked example I know of what “we have a platform” should mean.

Both series are now, finally, complete. Credit where it has belonged all along: to the DevMentors authors who built all of this in the open, samples and TODOs and Something failed included. The reading was mine; the thing worth reading was theirs. Go clone it.