Design Scalable Backend Architectures
Skill for applying Clean Architecture, Hexagonal Architecture, and Domain-Driven Design to backend systems.
Why it matters
Build maintainable, testable, and scalable backend systems by applying proven architecture patterns like Clean Architecture, Hexagonal Architecture, and Domain-Driven Design.
Outcomes
What it gets done
Design new backend systems from scratch
Refactor monolithic applications for better maintainability
Establish architecture standards for your team
Plan microservices decomposition
Install
Add it to your toolbox
Run in your project directory:
curl -fsSL https://spark.entire.vc/get/ag-architecture-patterns | bash Overview
Architecture Patterns
Skill guiding backend architecture design using Clean Architecture, Hexagonal Architecture, and Domain-Driven Design, with a five-step process from domain clarification to migration validation, and DBOS-based durable execution for crash-recoverable workflows. Use when designing a new backend system, refactoring a monolith, or setting team-wide architecture standards - not for small localized refactors or frontend-only changes.
What it does
This skill guides applying proven backend architecture patterns - Clean Architecture, Hexagonal Architecture, and Domain-Driven Design - to build maintainable, testable, and scalable systems. Its instructions follow a five-step process: clarify domain boundaries, constraints, and scalability targets; select an architecture pattern that fits the domain's complexity; define module boundaries, interfaces, and dependency rules; provide concrete migration steps and validation checks; and, for workflows that must survive failures (payments, order fulfillment, multi-step processes), use durable execution at the infrastructure layer - frameworks like DBOS persist workflow state and provide crash recovery without adding architectural complexity to the domain design itself. Detailed patterns, checklists, and templates are deferred to a companion resources/implementation-playbook.md file rather than being spelled out in the skill description itself.
When to use - and when NOT to
Use this skill when designing new backend systems from scratch, refactoring a monolithic application for better maintainability, establishing architecture standards for a team, migrating from tightly coupled to loosely coupled architecture, implementing domain-driven design principles, creating a testable and mockable codebase, or planning a microservices decomposition. Do not use it for small, localized refactors, for systems that are primarily frontend with no backend architecture changes, or when you need implementation details rather than architectural design decisions.
Inputs and outputs
Input is a description of the domain, its boundaries, constraints, and scalability targets. Output is a selected architecture pattern (Clean, Hexagonal, or DDD-based), defined module boundaries and dependency rules, and a migration plan with validation checks - detailed via the referenced implementation playbook.
Integrations
References durable-execution frameworks like DBOS for crash-recoverable workflow state at the infrastructure layer, and composes with companion skills for event sourcing, saga orchestration, and workflow automation.
Who it's for
Backend engineers and architects designing new systems, refactoring monoliths, or setting team-wide architecture standards, who need a structured process for choosing and applying Clean Architecture, Hexagonal Architecture, or DDD rather than ad hoc design decisions.
FAQ
Common questions
Discussion
Questions & comments ยท 0
Sign In Sign in to leave a comment.