Skill

Design Scalable Backend Architectures

Skill for applying Clean Architecture, Hexagonal Architecture, and Domain-Driven Design to backend systems.


71
Spark score
out of 100
Updated 16 days ago
Version 14.4.0

Add to Favorites

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

01

Design new backend systems from scratch

02

Refactor monolithic applications for better maintainability

03

Establish architecture standards for your team

04

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.