Service Classification Model¶
This document defines how every candidate is classified by delivery shape and, critically, when a candidate justifies an independent runtime. It is the core defense against service explosion and underpins ADR-0010 and ADR-0011.
Delivery Shapes¶
| Classification | What it is | Typical runtime |
|---|---|---|
| Platform Product | A whole product/platform (e.g., SaaS Control Plane) | Standalone deployable |
| Bounded Context | A context-owning service | Standalone service |
| Microservice | A focused service with a clear boundary | Standalone service (justified) |
| Module-in-service | A capability inside a bounded-context service | Module (no separate runtime) |
| Shared Library | Reusable code/SDK | NuGet/npm package |
| Infrastructure Component | Platform plumbing | Managed/infra |
| Connector | Integration adapter | Plugin in Connector Runtime |
| Portal/UI Module | UI surface | Blazor micro-frontend |
| AI Agent | An agent definition | Shared agent runtime |
| Workflow Template | A reusable workflow | Hosted by Workflow Orchestrator |
| Vertical Solution Pack | Pre-composed industry bundle | Composition (no new runtime) |
| Documentation Pattern | A documented pattern | None |
| Future Research | Not yet shaped | None |
The Microservice Justification Rule¶
A candidate becomes a standalone microservice only when it has a strong justification. It must satisfy most of:
- Independent lifecycle - releases on its own cadence.
- Clear bounded context - owns a distinct slice of the domain.
- Distinct scalability - different load/scaling profile from neighbors.
- Distinct data ownership - owns its own data store.
- Distinct security boundary - different trust/compliance requirements.
- External API/product boundary - exposed as a product or public API.
- Independent team ownership - a team can own it end-to-end.
Otherwise it is a Module-in-service inside its bounded-context service.
Decision
The default is module-in-service. Standalone runtimes are the exception and must be justified. See ADR-0011.
How The Catalog Applies This¶
The generator classifies each item heuristically from its name and category, marks inferred fields draft: true, and records runtimeCandidate (e.g., "Module within the Identity & Access service" vs "Standalone microservice (clear boundary)"). Architects refine these during each phase's deep-dive.
Outcome¶
Across 1,500 candidates we expect on the order of a few dozen independently deployed services and platforms, not 1,500 - the rest are modules, libraries, connectors, UI modules, agents, workflows, and packs.