architecture-patterns

Apply Clean Architecture, Hexagonal Ports and Adapters, and DDD principles to backend system design.

Updated Mar 5, 2026
One-click install
npx skills add https://github.com/truongnat/emplus --skill architecture-patterns-truongnat
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: architecture-patterns
Source: https://github.com/truongnat/emplus/tree/main/.agents/skills/architecture-patterns
Command: npx skills add https://github.com/truongnat/emplus --skill architecture-patterns-truongnat

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Architecture patterns prevent backend systems from becoming tightly coupled, hard to test, and expensive to change by guiding clean separation between domain logic and framework concerns.

Core Features & Use Cases

  • Clean Architecture guidance: Organize entities, use cases, interface adapters, and infrastructure so dependencies flow inward and business logic stays framework-agnostic.
  • Hexagonal Architecture (Ports & Adapters): Define ports for external interactions and implement adapters to enable swapping implementations and easy testing with mocks.
  • Domain-Driven Design (DDD): Model bounded contexts and ubiquitous language while using entities, value objects, aggregates, repositories, and domain events to keep invariants consistent.
  • Use case examples: Refactor a monolith into loosely coupled modules, standardize team architecture conventions, or plan microservices decomposition with a domain-first mindset.

Quick Start

Use the architecture-patterns skill to propose a Clean Architecture + Hexagonal Ports/Adapters folder layout for a backend feature, including the key domain models, use cases, port interfaces, adapter boundaries, and a small testing strategy.

Frequently Asked Questions about architecture-patterns

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I refactor a monolith into loosely coupled backend modules?

Refactor a monolith by applying Clean Architecture and Domain-Driven Design principles to define bounded contexts, establish inward dependency flow, and separate domain logic from framework concerns. This creates loosely coupled backend modules that are independently testable and easier to maintain.

What is the best way to make domain logic independently testable in a backend system?

Make domain logic independently testable by implementing Hexagonal Architecture (Ports and Adapters). Define port interfaces for external interactions and implement adapters to enable swapping implementations and easy testing with mocks, keeping the business core technology-agnostic.

How do I structure a backend project using Clean Architecture and Hexagonal Architecture?

Structure a backend project by organizing entities, use cases, interface adapters, and infrastructure so dependencies flow inward. Define ports for external interactions, implement adapters for swapping implementations, and keep the business core framework-agnostic.

When do I need Domain-Driven Design for microservice decomposition?

You need Domain-Driven Design for microservice decomposition when modeling complex systems with distinct bounded contexts. It helps model ubiquitous language, use aggregates and repositories, and define backend module boundaries with a domain-first mindset to ensure consistent invariants.

Does Clean Architecture work with my existing backend framework and infrastructure?

Clean Architecture works with existing backend frameworks by organizing infrastructure as outer layer adapters. It enforces inward dependency direction and port/adapter separation, ensuring your technology-agnostic business core remains independent of specific framework implementations.

Why does my tightly coupled backend system make adding new features expensive?

Tightly coupled backend systems become expensive to change because domain logic and framework concerns are mixed. Clean Architecture and Hexagonal Ports and Adapters solve this by enforcing clean separation, enabling swapping implementations, and making domain logic independently testable.