TIL

03. 코드 구성하기

계좌에서 다른 계좌로 돈을 송금하는 유스케이스를 예제로 육각형 아키텍처를 직접적으로 반영하는 표현력 있는 패키지를 소개하겠다.

계층으로 구성하기

buckpal
|---- domain
     |---- Acount
     |---- Activity
     |---- AccountRepository
     |---- AccountService
|---- persistence
     |---- AccountRepositoryImpl
|---- web
     |---- AccountController

• 웹, 도메인, 영속성 계층에 대해 패키지를 구성한 구조
• 최적의 구조가 아닌 이유
  • 애플리케이션 기능이나 특성을 구분 짓는 패키지 경계가 없다.
  • 애플리케이션이 어떤 유스케이스를 구현 했는지 파악할 수 없다.
  • 패키지 구조를 통해 우리가 목표로 하는 아키텍처를 파악할 수 없다.

기능으로 구성하기

buckpal
|---- account
     |---- Acount
     |---- AcountController
     |---- AccountRepository
     |---- AccountRepositoryImpl
     |---- SendMoneyService

• 계좌와 관련된 모든 코드를 최상위 account 패키지에 구성
• 패키지 간의 경계를 강화해 각 기능 사이 불필요한 의존성을 방지할 수 있다.
  • 외부에서 접근되면 안되는 클래스들에 대해 package-private 접근 수준을 이용해 패키지 간 경계를 강화할 수 있다.
• AccountService의 책임을 좁히기 위해 SendMoneyService로 클래스명 변경
  • 넓은 서비스 방지
  • ‘송금하기’ 유스케이스를 구현한 코드를 찾기 쉽게 되었음
• 최적의 구조가 아닌 이유
  • 계층 기반 패키징보다 아키텍처 가시성이 더 안좋다.
  • 어댑터, 포트를 찾을 수도 없고 도메인 코드가 영속성에 의존하는 것을 막을 수 없다.

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

• 육각형 아키텍처의 핵심 요소는 엔티티, 유스케이스, 인커밍/아웃고잉 포트, 인커밍/아웃고잉 어댑터다.

buckpal
|---- account
     |---- adapter
          |---- in
               |---- web
                    |---- AccountController
          |---- out
                |---- persistence
                     |---- AccountPersistenceAdapter
                     |---- SpringDataAccountRepository
     |---- domain
          |---- Account
          |---- Activity
     |---- application
          |---- SendMoneyService
               |---- port
                    |---- in
                         |---- SendMoneyUseCase
                    |---- out
                         |---- LoadAccountPort
                         |---- UpdateAccountStatePort

• 최상위에는 계좌와 관련된 유스케이스를 구현한 모듈임을 나타내는 account 패키지가 존재
• 도메인 모델이 속한 domain 패키지가 있으며 application 패키지는 도메인 모델을 둘러싼 서비스 계층
  • SendMoneyService는 인커밍 포트 인터페이스인 SendMoneyUseCase를 구현
  • SendMoneyService는 아웃고잉 인터페이스이자 영속성 어댑터에 의해 구현된 LoadAccountPort와 UpdateAccountStatePort를 사용한다.
• adapter 패키지는 애플리케이션 계층 내의 포트를 사용하는 어댑터를 포함한다
  • 이 예제에선 간단하게 web 어댑터와 persistence 어댑터로 구성된다.
  • web 어댑터에선 애플리케이션 계층의 인커밍 포트를 호출
  • persistence 어댑터는 애플리케이션 계층의 아웃고잉 포트 인터페이스를 구현
• 이 패키지 구조는 ‘아미텍처-코드 갭’ 혹은 ‘모델-코드 갭’을 효과적으로 다룰 수 있는 강력한 요소다.
  • 패키지 구조가 아키텍처를 반영
  • 아키텍처에 대한 적극적인 사고를 촉진
• 패키지가 많긴 하지만 모든 클래스를 public으로 열지 않아도 된다.
  • adapter 패키지의 모든 클래스들은 application 패키지 내 포트 인터페이스를 통하지 않고는 호출되지 않기에 package-private으로 충분하다.
  • 즉 애플리케이션 계층에서 어댑터 클래스로 향하는 우발적 의존성은 있을 수 없다.
  • 하지만 application과 domain 패키지 내 일부 어댑터에서 접근 가능해야 하는 포트들은 public으로 지정해야 한다
  • application 패키지 내 서비스는 인커밍 포트 뒤에 숨을 수 있기에 public일 필요가 없다.
• 어댑터 구현은 필요하면 다른 어댑터 구현으로 쉽게 교체할 수 있는 장점도 있다.
  • ex) RDBMS에서 NoSQL로 변경해야할 때 관련 아웃고잉 포트들만 새로운 어댑터 패키지에 구현하고 개존 패키지를 지우면 된다.
• 이 패키지 구조는 DDD 개념에 직접적으로 대응시킬 수 있다.
  • 예제 코드에서의 account 같은 상위 레벨 패키지는 다른 바운디드 컨텍스트와 통신할 전용 진입점 출구(포트)를 포함하는 바운디드 컨텍스트에 해당한다.

의존성 주입의 역할

• 클린 아키텍처의 본질적인 요건은 애플리케이션 계층이 인커밍/아웃고잉 어댑터에 의존성을 갖지 않는 것이다.
  • 웹 어댑터와 같은 인커밍 어댑터는 제어 흐름 방향과 코드 의존성 방향이 같아서 괜찮다.
    • 그럼에도 계층으로의 진입점을 구분 짓기 위해 실제 서비스를 포트 인터페이스들 사이에 숨겼다.
  • 하지만 영속성 어댑터와 같은 아웃고잉 어댑터는 제어 흐름과 코드 의존성이 반대이기 때문에 의존성을 역전시켜야 한다.
• 포트 인터페이스를 구현한 실제 클래스를 의존성 주입을 통해 초기화시킬 수 있다.
  • 스프링 DI