203 articles filed under this topic.
Unit tests mock what you assume, end-to-end tests tell you too late - consumer-driven contract testing closes the gap, and a small open-source .NET library called Pactify is the clearest way I know to learn how it works. Part 1 of a series.
The 22-part Convey series read the packages; it never once walked the sample system that ships with them. Opening the missing chapters with the trip an order takes through Orders, Pricing and Deliveries — and what the samples quietly teach that no package README does.
Most repositories ship code and a README - this one ships four ADRs with a named approver, a context map, a domain message flow and a methodology poster. Part 1 of a series that reads the strategic half of DevMentors' GroupFlights.
Every team's fifth microservice ships with the same four hundred lines of bootstrap code as the first four. Opening a deep-dive series on Convey, the open-source .NET toolkit that turned that boilerplate into thirty composable packages.
DShop is one e-commerce shop stamped out as nine microservices over RabbitMQ - this series reads the real source to see how the topology holds together and where it drifts. Part 1 of Nine Services and a Message Bus.
Every modular monolith promises you can extract a module later. Inflow has a branch where someone actually did it - one module lifted into its own process behind a gateway and a real broker. This series reads that branch line by line.
DevMentors built the same e-commerce shop twice - once as a monolith, once as nine services - with two gateways and two frontends. This series reads the whole estate as one artefact.
A guided tour of FeedR, DevMentors' open-source .NET microservices sample for real-time data feeds - six services, Redis pub/sub, Apache Pulsar and a gRPC stream, and the two-tier eventing model that makes it worth reading. Part 1 of a source-level deep dive.
Split one database into five services and the transaction you deleted does not disappear - it goes feral. On sagas, compensation, process managers, and Chronicle, the small open-source .NET library this series reads line by line.
Convey sells a microservice in thirty lines, and Pacco builds ten of them - this series reads the whole estate to price what the framework compresses and what every consumer pays for by hand. Part 1 of The Convey Consumer Tax.
Nobody in Pacco approves an order - a vehicle reservation does. A tour of DevMentors' parcel-delivery estate, the domain it models, and the fifteen-part series it earns.
DevMentors shipped Trill as nine microservice repos, then rebuilt the identical product as a modular monolith three months later - giving us a controlled experiment in architecture that almost never exists in public.
Trill's Stories service is four projects with a dependency-free domain at the bottom. Its Users service is two projects with everything in one assembly - same author, same week, same estate, opposite answers to what a layer is.
The DevMentors Trill estate is a nine-service microservices sample spread over eleven sibling repositories with no README, no clone script and no bootstrap tooling - and the only artefact that names the whole system is a Visual Studio solution file.
Thirteen repositories, one umbrella that runs twelve of them, two interchangeable API gateways and a service that watches everything - the Pacco estate read as a system of systems, and the fifteen-part series it earns.
The series retrospective - Pacco's domain teaches real rules (state machines, priority expropriation, loyalty ladders, compensations) on top of cardboard data (bare-decimal prices, one vehicle per order, size-cube parcels, no payment, and a capacity check that ships in two halves nobody ever connects). What to steal, what to distrust, and what fourteen parts of source-reading add up to.
Availability guards every save with a version-filtered ReplaceOneAsync - and discards the result, so a lost update is indistinguishable from a successful one and the integration event ships either way. Three folders away, Orders and Customers inherit the same AggregateRoot name with the versioning quietly deleted.
In Pacco the CQRS split is not a diagram - it is wiring you can read. Every command arrives through two front doors, RabbitMQ subscription and controller-less HTTP dispatch, while queries ride HTTP only; commands assign their own ids in the constructor, and a marker attribute turns each service into its own runtime contract registry.
Every Pacco service that enables Convey's Mongo outbox also sets disableTransactions to true - the aggregate write and the outbox write are separate operations, the pattern's one guarantee switched off in configuration. Meanwhile the inbox that would absorb the resulting duplicates sits beside three handlers that throw on them.
Four Pacco services need customer data and no two agree on how to get it - Orders and Parcels keep id-only replicas fed by events, Availability phones home mid-command, and Pricing pulls the full details document to count one number. One upstream, three consistency stances, five representations of the same entity.
Inside the Customers service a registration completes - and the rest of the estate hears that a customer was created. Three lines of EventMapper perform the best ubiquitous-language translation in Pacco, sitting on top of a lifecycle state machine with one guarded transition and four administrative jumps.
Order.DeleteParcel raises a ParcelDeleted event and never removes the parcel from the set, while Parcels' cancel and delete handlers detach exactly one parcel of many. Two bounded contexts maintain the same association independently, both with bugs, and end up permanently disagreeing about a fact.
Convey's IRejectedEvent gives Pacco an application-level negative acknowledgement - a rejected twin for every command. Reading the four exception-to-message mappers shows the pattern decaying in four different ways, from a failed reserve announced as a failed release to rejection classes nothing ever constructs.
Availability's ResourceReserved event carries no order id, no correlation id, no saga id - just a resource and a date. Orders finds the right order anyway, by treating (vehicleId, deliveryDate) as the correlation key, and the expropriation flow shows exactly when that key stops being unique.
Pacco's flagship flow reconstructed from source - a vehicle is assigned, a reservation lands, an order approves itself, and when a VIP bumps the booking the cancellation ripples through three services with no process manager in sight.
Every transition of Pacco's Order raises the same domain event - OrderStateChanged - and a mapper switches on aggregate status to mint five distinct integration events. A content-based router keyed on state, weighed honestly.
Availability's Resource aggregate enforces one real business rule - a higher-priority reservation evicts yours and announces it. The invariant, the struct value object behind it, and the day-integer it becomes on disk.
Nobody in Pacco approves an order - a vehicle reservation does. A tour of DevMentors' parcel-delivery estate, the domain it models, and the fifteen-part series it earns.
Same framework, same four-project layout, three maturities - Parcels publishes from handlers, Orders raises events and maps them inline, Availability runs a full pipeline. The lineage made diffable.
The retrospective that closes three series on DShop - the whole map drawn once, the services wired into nothing, the skew across seventeen repos, and what reading someone else's estate end to end actually teaches.
DShop.Api ships three Dockerfiles - plain, multistage, and multistage.advanced - as a teaching ladder. The top rung is broken, and all three share an ENTRYPOINT that quietly defeats graceful shutdown.
DShop wires Serilog, App.Metrics and Jaeger through one shared kernel, propagates a trace span on the message envelope, and hangs its Consul health check on an endpoint no controller defines. A tour of pre-OpenTelemetry observability.
DShop.Blazor is a Blazor 0.7 preview app whose naive choices - component classes as singletons, a silent auto-signup, a shared HttpClient - all work because of the runtime they run on. A study in patterns that are only correct by accident.
DShop.Web is a well-structured Angular 6 SPA whose plumbing leaks at every joint - an auth header discarded, PUT and DELETE that both GET, a paged result that starts empty. A tour of bugs that only survive because nobody ran the code.
DShop has an Angular 6 SPA and a Blazor 0.7 WASM app over the same gateway. One has the right architecture and broken plumbing; the other has naive architecture and a working shop. The contrast is the lesson.
DShop runs a whole SignalR service to push operation results to the browser in real time - JWT handshake, per-user groups, Redis backplane. No frontend connects to it, and both UIs sleep through eventual consistency instead.
DShop's gateway answers a write with 202 Accepted and a header pointing at an operation that hasn't happened yet. Reading the contract shows a clean async-REST design - and two small bugs that undercut it.
DShop puts all its authorization at the gateway and none in the services behind it - then publishes every service port to the host. The compose file quietly defeats the entire security model.
DShop.Api.Next rebuilds the whole code-first gateway as Ntrada configuration - a 17-line Program.cs and a folder of YAML. Reading both side by side shows exactly what you trade when a gateway becomes data.
DShop's gateway reads over HTTP and writes over a message bus - two dispatch mechanisms behind one controller. Reading it shows how a gateway can be a router and a publisher at the same time.
