만들면서 배우는 클린 아키텍처 - (3) 코드 구성하기

본 책에서 다루는 예제를 바탕으로 하고 있습니다.

 

계층으로 구성하기

인터페이스 & 인터페이스 구현체 → 최적은 아님…

문제점 :

• functional slice나 feature를 구분 짓는 패키지 경계가 없다.
• 애플리케이션이 어떤 유스케이스들을 제공하는지 파악 불가

 

 

기능으로 구성하기

상위 패키지 안에 다 때려넣기

장점 :

• 패키지 경기를 package-private 접근 수준과 결합하면 기능 사이의 불필요한 의존성 방지 가능
• AccountService의 책임을 좁히기 위해 SendMoneyService. → 기능과 의도를 소리치고 있음!

단점 :

• 가시성 떨어짐
• 의존성 역전을 시켰지만, 도메인 코드가 실수로 영속성 코드에 의존하는 것을 막을 수 없다.

 

 

아키텍처적으로 표현력 있는 패키지 구조

• adapter
  • 애플리케이션 계층의 인커밍 포트를 호출하는 인커밍 어댑터 포함
  • 애플리케이션 계층의 아웃고잉 포트 구현을 제공하는 아웃고잉 어댑터 포함
• domain
  • 도메인 모델이 속함
• application
  • 도메인 모델을 둘러싼 서비스 계층을 포함
  • SendMoneyService는 인커밍 포트 인터페이스인 SendMoneyUseCase를 구현
  • 아웃고잉 포트 인터페이스이자 영속성 어댑터에 의해 구현된 LoadAccountPort와 UpdateAccountStatePort를 사용

 

 

패키지가 많은데 혹시 모든걸 다 public으로 접근 허용??

→ 최소한 어댑터 패키지에 대해서는 NO

 

 

application 패키지 내에 있는 포트 인터페이스을 통해서만 바깥으로 나가기 때문에 package-private 으로 둬도 됨.

하지만 application, domain 패키지의 일부 클래스는 public으로 지정해야 함.

• 의도적으로 어댑터에서 접근 가능해야 하는 포트들은 public
• domain 클래스들은 서비스, 어댑터에서도 접근 가능해야 하므로 public
• 서비스는 인커밍 포트 인터페이스 뒤에 숨겨지므로 public일 필요 없음

 

 

어댑터 코드를 자체 패키지로 이동시키면 필요할 경우 쉽게 교체 가능

• db를 교체한다면 아웃고잉 포트들만 새로운 어댑터 패키지에 구현하면 됨

 

DDD 개념에 직접적으로 대응 가능

 

 

의존성 주입의 역할

클린 아키텍처의 본질 : 애플리케이션 계층이 인커밍/아웃고잉 어댑터에 의존성을 갖지 않는 것

• 인커밍 어댑터는 수월
• 아웃고잉 어댑터는 제어 흐름의 반대 방향으로 의존성을 돌려야 하므로 DIP 이용해야 함
  • 포트!
  • 포트를 구현한 실제 객체를 누가 애플리케이션 계층에 제공?
    → 모든 계층에 의존성을 가진 중립적인 컴포넌트 도입!! 이 컴포넌트는 대부분의 클래스를 초기화해줌

 

 

---

「만들면서 배우는 클린 아키텍처-자바 코드로 구현하는 클린 웹 애플리케이션」 을 읽고 개인 학습용으로 정리한 내용입니다.