Health checks. Structured logging. Retry policies with jitter. Everyone who writes a "production readiness checklist" for a .NET Core service reaches for the same list, and none of it is wrong. But it's the wrong list to reach for first if your services live inside a shared domain model.
I spent a chunk of this month wiring up something that's not on anyone's checklist: turning our domain projects into versioned NuGet packages, pushing them to a private Artifactory feed, and building a bot whose entire job is bumping the version number and rippling that bump out to every microservice repo that consumes it.
It sounds like plumbing. It is plumbing. But it's the plumbing that decides whether "production-ready" means anything across a fleet of services instead of just one.
Here's the problem it solves. Once you factor shared domain logic — entities, value objects, business rules that more than one service needs — out of a monolith and into a library, you've created a dependency graph you didn't have before. Every consuming service now has an opinion, implicit or not, about which version of that library it's running. Before we packaged it properly, that opinion was enforced by copy-paste and tribal memory. Nobody actually knew which service had which version of which rule.
