Agent Skills: The Service-Based Architecture Paradigm

'Coarse-grained service architecture for deployment independence without

UncategorizedID: athola/claude-night-market/architecture-paradigm-service-based

Install this agent skill to your local

pnpm dlx add-skill https://github.com/athola/claude-night-market/tree/HEAD/plugins/archetypes/skills/architecture-paradigm-service-based

Skill Files

Browse the full folder contents for architecture-paradigm-service-based.

Download Skill

Loading file tree…

plugins/archetypes/skills/architecture-paradigm-service-based/SKILL.md

Skill Metadata

Name
architecture-paradigm-service-based
Description
'Design coarse-grained service architecture for deployment independence without microservices complexity and overhead.'

The Service-Based Architecture Paradigm

When To Use

  • Multi-team organizations with domain-aligned services
  • Systems requiring independent deployment of components

When NOT To Use

  • Single-team projects small enough for a monolith
  • Latency-sensitive systems where inter-service calls are prohibitive

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

  1. Group Capabilities: Bundle related business functions into a small set of well-defined services, each with a designated owner.
  2. Define Service Contracts: Publish formal specifications using standards like OpenAPI or AsyncAPI, including Service Level Agreements (SLAs) and a clear versioning strategy.
  3. 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.
  4. Establish Service Mediation: Use a service registry or an API gateway to handle routing, authentication, and observability.
  5. 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 validate 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.