# Book Clean Architecture Nano

> Clean Architecture (Robert C. Martin) — Minimal rules — essential one-liners only. Use when asked to apply Clean Architecture principles or review code against Clean Architecture standards.

- Skill: `yanacuti1121/book-clean-architecture-nano` (Agent Skill)
- Install (CLI): `npx skillmds add yanacuti1121/book-clean-architecture-nano`
- Raw SKILL.md: https://api.skillmd.com/api/skills/yanacuti1121/book-clean-architecture-nano/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: MIT
- Author: yanacuti1121 (https://skillmd.com/u/yanacuti1121)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/yanacuti1121/book-clean-architecture-nano

---


# OBEY Clean Architecture by Robert C. Martin

## When to use

Use when tight context still needs to prevent framework-first design, database-shaped policy, layer bypass, or fake boundaries.

## Primary bias to correct

Details are plugins to policy, not the center of the design.

## Decision rules

- Source dependencies point inward. Domain and use cases must not import frameworks, databases, web, UI, queues, service clients, device, vendor, or infrastructure details.
- Entities guard enterprise invariants; focused use cases orchestrate application actions with plain input and output models.
- Frameworks, databases, web delivery, messaging, filesystems, clocks, networks, services, and hardware sit behind policy-owned ports and outer-layer adapters.
- Controllers, presenters, gateways, service listeners, mappers, and hardware adapters translate; they do not own business rules.
- Organize by use case, feature, or business capability. Avoid generic technical buckets, god services, shared utility escape hatches, and sideways coupling.
- Choose the lightest enforceable boundary that preserves likely change independence; a service, package, diagram, or folder name is not enough.
- Test policy through entities, use cases, and boundary contracts without real frameworks, databases, networks, services, or hardware.

## Trigger rules

- When framework, ORM, request, response, schema, transport, config, vendor, or hardware types enter core policy, move translation outward.
- When controllers, jobs, handlers, gateways, repositories, SQL, presenters, service listeners, or `*Service` classes grow business rules, move policy inward and split by use case.
- When core code constructs or calls volatile details directly, define an inward-owned port and wire the concrete implementation at the edge.
- When a shortcut bypasses a use case, crosses layers, creates a cycle, or hides coupling in `common` or `utils`, restore dependency direction and ownership.
- When constraints force a compromise, keep it outermost, name the violation, and preserve a future path to separation.

## Final checklist

- Policy independent of details?
- Dependencies inward?
- Use cases visible?
- Adapters humble?
- Boundaries enforced?
- Core tests detail-free?