Three Ages of a Domain Model
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.
Archive
Every article
Newest first, grouped by year. Search or filter by topic.
- 556 articles
- 67 matching
All
.NET
AI Engineering
Architecture
Azure & DevOps
Data Warehousing
Engineering Practice
Microservices
Web APIs
rabbitmq ×
One Shop, Two Front Doors
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.
Swap the Dispatcher for a Bus
The monolith and the microservices share the same command names. Decomposition here was one substitution - resolve a local handler, or publish to a broker - and reading both dispatchers shows exactly what changes.
Idempotency Aspired, Not Enforced
DShop runs competing consumers over an at-least-once bus with no message-id dedup, so a redelivered reservation decrements stock twice - the estate aspires to idempotency and enforces none of it. Part 9 of Nine Services and a Message Bus.
One Orchestrator Subscribes to Everything
Operations subscribes to every command and event in the estate by reflection and routes them through two open-generic handlers - a neat trick with one dead limb the wiring can never light. Part 8 of Nine Services and a Message Bus.
OrderCreated in Three Shapes
The same event is declared three times across DShop, and one copy quietly drops a field - here is the contract drift in the real source and the canonical-model cure that would have caught it. Part 3 of Nine Services and a Message Bus.
Nine Services and a Message Bus
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.
The Retry Path Nobody Took
A complete broker-requeue retry implementation sits in DShop.Common's subscriber, fully written and never called - and its comment explains exactly why.
Rejected Events — a Two-Lane Error Taxonomy
DShop.Common decides a message's fate from the type of exception a handler throws - domain failures become events, infrastructure failures get retried.
Command or Event, Enforced by Convention
In DShop.Common a command and an event are published by identical code - the difference between them is a marker interface and a promise nothing enforces.
Queue Names Are the Whole Topology
One naming class in DShop.Common decides every exchange, routing key and queue in the estate - the message topology is a string-formatting problem.
The Framework Before the Framework
DShop.Common is the shared library nine microservices were built on - and the rough draft of a framework its authors later shipped as Convey.
Commands and Events on the Wire
Convey's broker-CQRS bridge is seventy lines of code that make the same handler serve local dispatch and RabbitMQ delivery — one line per subscription, correlation context riding along for free.
The Outbox That Keeps Your Events Honest
Save the order, publish the event, crash in between - the dual-write problem, and how Convey's outbox and inbox turn at-least-once messaging into something you can build a business on.
Retries, Dead Letters, and the Plugin Chain
What Convey's RabbitMQ subscriber actually does when your handler throws - fixed-interval retries, an exception-to-message escape hatch, a dlx- safety net, and one plugin that can quietly defeat all of it.
A Message Broker Behind an Interface
Convey's messaging abstraction is two interfaces and an attribute - and the naming conventions underneath them quietly turn your C# class names into a public wire contract.
RabbitMQ by Convention
How Convey's RabbitMQ package turns a class name into an exchange, a routing key and a queue - two eager connections, a channel per thread, and a topology you never declare by hand.