architecture-placement

To place domain rules and orchestration in Clean Architecture, map responsibilities to specific layers: entities and value objects hold domain rules, use cases handle orchestration, and adapters manage integration mechanics. This separation prevents business logic from leaking into controllers or infrastructure code.

Responsibility mapping in DDD and Hexagonal Architecture classifies behavior into entities, value objects, domain services, ports, and adapters. It enforces inward dependencies so domain rules remain isolated from infrastructure concerns like database schemas or API controllers.

To spot boundary violations during a code review, check for business rules placed in controllers, formulas embedded in use cases, or foreign DTOs leaking inward. Enforce inward dependencies to ensure infrastructure concerns do not pollute the domain model.

Yes, you can use this approach to refactor legacy modules toward Onion Architecture. It supports reshaping existing code by explicitly placing repositories, readers, and gateways while enforcing boundary checks to separate orchestration from domain rules.

You need explicit placement of ports and adapters when planning features that require strict separation between domain logic and integration mechanics. This ensures gateways and repositories handle external dependencies while use cases remain focused on orchestration.