Clean Architecture

• · CA1 — Dependencies point inward. No inner-ring file imports an outer-ring concrete type. Enforced by import-direction linting where the team's size justifies it.
• · CA2 — Business rules are framework-agnostic. Entities and use cases compile and test without the web framework, the ORM, or a running database.
• · CA3 — Interfaces are owned by the inner ring. OrderRepository is defined next to the use case that needs it, not next to its SQL implementation — the consumer owns the contract.
• · CA4 — One composition root. Concrete wiring (which database, which framework) happens in exactly one place per deployable; everywhere else depends on interfaces.
• · CA5 — Screaming architecture. Top-level folder/module names describe what the system does, not the frameworks it uses.

• · The import test: open a use-case file; if it imports anything from a framework/ORM/HTTP library, that's a boundary violation — extract an interface.
• · The unplug test: could business logic be tested by unplugging the database and web framework entirely, using in-memory fakes? If no, the dependency rule isn't holding yet.
• · The screaming test: look at top-level folders; do they say "orders, billing, shipping" or "controllers, models, services"? The latter is framework-organized, not business-organized.
• · Boundary placement follows the volatility axis. Put interfaces where things are likely to change independently (payment providers, notification channels) — not around stable, unlikely-to-change internals.
• · When in doubt, favor the simpler structure and a documented tripwire ("add a repository interface here if we ever support a second database") over speculative abstraction today.

• · Ver anti-patrones específicos del dominio en el pack.

• [ ] Business-rule tests run without database/network/framework. (CR4)
• [ ] No domain/use-case file imports framework/ORM/HTTP packages. (CR1)
• [ ] External dependencies (persistence, notifications, third-party APIs) expressed as interfaces owned by the core. (CR2)
• [ ] Data crossing boundaries is plain DTOs, not ORM/framework objects. (CR5)
• [ ] One composition root per deployable; it wires, doesn't decide. (CR3)
• [ ] Controllers/handlers are humble — no inline business rules. (CR7)

• Clean Architecture: A Craftsman's Guide to Software Structure and Design

Este pack cita las siguientes fuentes registradas en el índice bibliográfico:

• bookClean Architecture: A Craftsman's Guide to Software Structure and DesignRobert C. Martin. Prentice Hall
• webHexagonal Architecture (Ports and Adapters)Alistair Cockburn
• blogThe Clean Architecture (blog)Robert C. Martin