clean-architecture

Identify outward dependencies in inner layers, define interfaces in the inner circle describing what it needs, move concrete implementations outward, and wire everything in a Main composition root. This four-step inversion process works for any violation.

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 represents a single application operation like PlaceOrder or CancelOrder.

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 avoid shared databases or shared data models.

Use the two-model approach: keep pure domain entities in the inner circle and ORM-annotated persistence models in the adapter layer. Gateways map between the two, so schema changes never ripple into business rules.

Use partial boundaries when the anticipated need does not justify the cost of reciprocal ports and DTOs. Options include interfaces within one package, the strategy pattern, or a facade, reserving full boundaries for points of likely volatility.