| name | architecture-paradigm-service-based |
| description | Employ a coarse-grained, service-based architecture (a lighter form of SOA) when microservices are not yet necessary but modular deployment is required. Use when building coarse-grained service-oriented systems. |
| version | 1.0.0 |
| category | architectural-pattern |
| tags | architecture, service-based, soa, modular, shared-database |
| dependencies | |
| tools | api-gateway, service-registry, schema-management |
| usage_patterns | paradigm-implementation, monolith-refactoring, deployment-independence |
| complexity | medium |
| estimated_tokens | 700 |
The Service-Based Architecture Paradigm
When to Employ This Paradigm
- When teams require a degree of deployment independence but are not yet prepared for the complexity of managing numerous microservices.
- When shared databases or large-scale systems (like ERPs) make full service autonomy unrealistic.
- When establishing clear service contracts for partner teams or external consumers.
Adoption Steps
- Group Capabilities: Bundle related business functions into a small set of well-defined services, each with a designated owner.
- Define Service Contracts: Publish formal specifications using standards like OpenAPI or AsyncAPI, including Service Level Agreements (SLAs) and a clear versioning strategy.
- Control Database Schemas: Even when services share a database, assign explicit ownership for each schema or table. Gate all breaking changes through a formal review process.
- Establish Service Mediation: Use a service registry or an API gateway to handle routing, authentication, and observability.
- Plan for Evolution: Identify architectural "hotspots" that are likely candidates for being split into more granular services in the future.
Key Deliverables
- An Architecture Decision Record (ADR) that outlines service boundaries, data ownership rules, and coordination mechanisms.
- A suite of contract tests and consumer-driven contract tests for each service to ensure stability.
- Runbooks that describe deployment procedures, rollback plans, and service dependencies.
Risks & Mitigations
- Coupling Through a Shared Database:
- Mitigation: Changes to a shared database can have cascading effects across services. Mitigate this by using database views, replication, or a formal schema deprecation schedule to manage change.
- Architectural Degradation:
- Mitigation: Without strong governance, this architecture can degrade into a "distributed monolith"—a monolith with the added complexity of network hops. Track coupling metrics closely and enforce strict ownership of services and data to prevent this.