clean-architecture

Organize code into concentric circles with entities innermost, then use cases, adapters, and frameworks outermost. Ensure all source code dependencies point inward by defining interfaces in inner circles and implementing them in outer circles via dependency inversion.

Entities encapsulate enterprise-wide business rules that would exist without software, while use cases contain application-specific rules orchestrating data flow to and from entities. Each use case is a single operation like PlaceOrder, implemented as an interactor behind input and output ports.

Separate domain entities from persistence models and map between them in gateway classes at the adapter layer. Domain entities carry business rules with no ORM annotations, while persistence models handle database schema concerns.

Yes, but services are deployment boundaries, not automatic architectural boundaries. Each service should apply the Dependency Rule internally with its own circles; a microservice sharing a database or data model is a distributed monolith.

Use full boundaries with reciprocal ports when you will definitely swap implementations. Use partial boundaries like the strategy pattern or facade when the need is uncertain, since full boundaries add interfaces, DTOs, and wiring cost.

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