• 도메인 계층(서비스)가 영속성 계층(엔티티, 리포지토리)에 의존하지 않도록 DIP를 적용함

• 유스케이스 : 서비스. 접근하는 도메인 엔티티들 단일 책임 지키기 위해 세분화(넓은 서비스 문제 피하기 위해)

• 도메인 코드(서비스)에서는 어떤 영속성 프레임워크나 UI 프레임워크가 사용되는 지 알수 없기 때문에 특정 프레임워크에 특화된 코드를 가질 수 없고 비즈니스 규칙에 집중할 수 있다.
• 클린 아키텍처에는 대가가 따름. 도메인 계층이 영속성이나 UI 같은 외부 계층과 철저하게 분리돼야 하므로 어플리케이션의 엔티티에 대한 모델을 각 계층에서 유지보수 해야함!
• 가령 영속성 계층에서 ORM 프레임워크를 사용한다 했을 때, 엔티티 클래스를 필요로 함
• 도메인 계층은 영속성 계층을 모르기 때문에 도메인 계층에서 사용한 엔티티 클래스를 영속성 계층에서 함께 사용할 수 없고 두 계층에서 각각 엔티티를 만들어야 함 ⇒ 즉, 도메인 계층과 영속성 계층이 데이터를 주고 받을 때 두 엔티티를 서로 변환해야 한다는 뜻임
• 이는 도메인 계층과 다른 계층들 사이에서도 마찬가지