Finding OmNomNom's service boundaries
Walking OmNomNom through the questions from the previous post and landing on five boundaries that are nothing like Product, Order, Customer, and Payment.
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.
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.
The four values that change when you swap identity providers, the audit instance that mirrors them, the forwarded headers ServiceControl trusts behind a reverse proxy, and the moment the browser finally lands back in ServicePulse with a token.
A realm, a client scope, the audience mapper that catches every first-time setup, and the public client ServicePulse uses to redirect through Keycloak.
ServiceControl 6.13 lets ServicePulse sit behind any OpenID Connect identity provider. This series wires it to Keycloak in Docker, end to end, on a home server.