The Order That Choreographs Itself
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.
Archive
Every article
Newest first, grouped by year. Search or filter by topic.
- 556 articles
- 152 matching
All
.NET
AI Engineering
Architecture
Azure & DevOps
Data Warehousing
Engineering Practice
Microservices
Web APIs
microservices ×
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.
Cartography of an Estate
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.
A Pedagogy Ladder of Dockerfiles
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.
The Observability Stack of 2018
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.
The Blazor App That Signs You Up Behind Your Back
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.
The Angular App That Forgot Its Auth Header
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.
Two Frontends, One API
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.
The Push Channel Nobody Plugged In
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.
The Header That Names the Future
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.
The Security Inversion
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.
A Gateway Written in YAML
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.
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.
The Buy Path That Never Worked
The DShop monolith was abandoned with a NotImplementedException sitting directly in the order path. Reading its honest ledger is a masterclass in what an unfinished codebase confesses about itself.
Who Creates the Customer?
In DShop a customer is born in two steps - a record on sign-up, then a completed profile. Following both across the monolith and the swarm shows how a consistency model quietly rewrites a user flow.
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.
One Shop, Every Shape
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.
The Monolith and the Swarm
DShop exists as one deployable and as nine services built from the same requirements. Read side by side, the two builds show which decisions were decisions and which were defaults.
Rich Domain, Honest Stubs
A retrospective on nine DShop services - the order aggregate and checkout saga that genuinely work, sitting next to the discount that only prints, the emails that never send, and a currency guard that guards nothing. Part 15 of Nine Services and a Message Bus.
Identity Done Mostly Right, Secrets Done Wrong
The Identity service gets the hard parts of auth genuinely right - issue, refresh, revoke - and then commits its signing key to source control and ships a CORS policy the spec forbids. Part 13 of Nine Services and a Message Bus.
The Test Folder That Lies
Nine DShop services ship a tests folder and only one of them tests anything - a census where five test projects cannot even see the code they claim to cover and the lone unit test asserts a thing that never happens. Part 14 of Nine Services and a Message Bus.
Four Products, One Truth
A single product identity is represented four ways across four DShop services - owner, replica, cart snapshot, order snapshot - each on its own refresh discipline, and nothing masters the set. Part 12 of Nine Services and a Message Bus.
CQRS Across a Service Boundary
Storage subscribes to almost every event in DShop, serves read-only queries, and owns nothing it cannot rebuild - the read side of a CQRS split that runs across a service boundary instead of inside one. Part 10 of Nine Services and a Message Bus.
The Version-Skew Time Capsule
One DShop service targets a different framework, references a frozen NuGet package, and calls an API that no longer exists in the repo - so its Debug configuration cannot compile, and it only builds in Release. Part 11 of Nine Services and a Message Bus.
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.