clean-architecture

The Dependency Rule requires that source code dependencies point only inward, from frameworks toward use cases and entities. Define interfaces in inner circles, implement them in outer circles, and wire concrete implementations in a Main composition root.

Entities encapsulate enterprise-wide business rules that would exist without any software system, while use cases contain application-specific rules that orchestrate entities for a single operation. Use cases accept request DTOs and return response DTOs, never framework objects.

Separate domain entities from persistence models and map between them in gateway classes at the adapter layer. Business logic should call repository interfaces like save or find_by_id, never raw SQL or ORM-annotated classes.

Yes, but services are deployment boundaries, not automatic architectural boundaries. Each service should apply the Dependency Rule internally with its own entities, use cases, and adapters, and must own its data store to avoid becoming a distributed monolith.

Use a full boundary with input and output ports when you will definitely swap implementations. Use a strategy pattern or facade as a partial boundary when the need is uncertain, since full boundaries carry higher design and maintenance cost.

Apply the Acyclic Dependencies Principle using two strategies: invert a dependency by extracting an interface one side implements, or extract the shared code into a new component both sides depend on. The component graph must remain a directed acyclic graph.