Backend Architecture Patterns

Problem

Backend code often becomes hard to test and hard to split when boundaries are unclear, dependency direction is weak, and business rules leak into controllers, repositories, and SQL. This skill is for architecture trade-off decisions, not for replacing a specific framework implementation.

How It Works

It starts from three established backend patterns: Clean Architecture, Hexagonal Architecture, and Domain-Driven Design, and helps engineers make domain boundaries, interfaces, dependencies, and migration paths explicit. The core steps include:
- Clarify domain boundaries, constraints, and scalability goals
- Choose a pattern that matches the domain complexity
- Define module boundaries, interfaces, and dependency rules
- Provide migration steps and validation checks

The material emphasizes mockable, testable, and splittable code structure, which is useful as a decision checklist when evolving a monolith or planning microservice boundaries.

Scope

Skip it if the task is a local function-level refactor, the system is primarily frontend, or the goal is implementation detail rather than architecture. It provides an architecture judgment and review framework; concrete technology choices still depend on language, framework, and team constraints.