I'm a developer, international speaker and coach/trainer. I love to discuss code, software architecture and distributed systems, messaging, star wars and lego with anyone who wants to listen or speak.
I currently work at Particular Software on NServiceBus.
A product identifier lets services work independently. A product list first needs someone to select the products. How composition events provide that context without a central controller knowing every service.
Catalog owns the name, Finance owns the price, and Marketing owns the rating. How does OmNomNom turn those separate contributions into one product page?
AI may be in a bubble, but Jevons' paradox suggests cheaper intelligence will make usage and infrastructure demand explode anyway.
Walking OmNomNom through the questions from the previous post and landing on five boundaries that are nothing like Product, Order, Customer, and Payment.
Service boundaries are not named into existence. They are discovered by asking who actually gets to decide, what handoffs exist, and where authority quietly leaks.
Service boundaries are not about data shape or workflow. They are about authority, and most diagrams skip the part that matters.
The four ServiceControl env vars from Part 3, repointed at Duende. Same login flow, same audience validation, different IdP.
A minimal ASP.NET Core app embedding Duende IdentityServer, configured for the same servicecontrol-api audience the Keycloak path uses. Same SPA flow, different IdP, more code.
The error messages every first-time setup hits, what each one actually means, the fix, and the list of things that need to change before this configuration leaves the lab.