# Tdd Architecture Patterns

> Designing testable software systems using established architectural patterns.

- Skill: `jcorpac/tdd-architecture-patterns` (Agent Skill)
- Install (CLI): `npx skillmds@latest add jcorpac/tdd-architecture-patterns`
- Raw SKILL.md: https://api.skillmd.com/api/skills/jcorpac/tdd-architecture-patterns/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: jcorpac (https://skillmd.com/u/jcorpac)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/jcorpac/tdd-architecture-patterns

---


# TDD Architecture Patterns

Software architecture should enable testing, not hinder it. These patterns ensure your system remains decoupled and verifiable.

## Core Patterns

### 1. Hexagonal Architecture (Ports & Adapters)
- Keep your business logic (the Core) isolated from external concerns (DB, UI, APIs).
- Use **Ports** (interfaces) for the core to communicate with the outside world.
- Use **Adapters** to implement those ports for specific technologies.

### 2. Dependency Injection (DI)
- Invert the control of dependencies. Instead of a class creating its helper, it receives it via a constructor or parameter.
- **Benefit**: Allows you to easily swap real dependencies with mocks in tests.

### 3. SOLID Principles
- **S**: Single Responsibility.
- **O**: Open/Closed (Open for extension, closed for modification).
- **L**: Liskov Substitution.
- **I**: Interface Segregation.
- **D**: Dependency Inversion.

## Guidelines
- **Avoid Global State**: It makes tests non-deterministic and hard to run in parallel.
- **Keep Logic Pure**: Prefer stateless functions where possible; they are the easiest to test.
- **Test-First Design**: If a feature is hard to test, it usually means the architecture is too tightly coupled.