[클린 아키텍처 03] 코드 구성하기

 

<< 클린 아키텍처 03>>

코드 구성하기

계층으로 구성하기

Web, Domain, Persistence의 구조로 패키지를 구성한다.

요렇게 구성하는 경우의 문제점은?

 

1) 기능이나 특성을 구분짓는 경계가 없음 

만약 User 기능이 추가 된다면...?

서로 연관되지 않은 기능끼리 마구마구 섞임 (domain 패키지에 user repo, service, user entity 모두 추가됨 ㄷㄷ)

 

2) 어떤 유스케이스가 있는지 파악 불가

AccountController에는 어떤 기능이 있을까..? User Controller에는..?

기능으로 구성하기

Account 패키지 안에 몽땅 넣는다!

그 와중에 AccountService 네이밍을 SendMoneyService로 변경함

이렇게 구성할 경우 '송금하기' 기능이 어딨는지 파악 가능하긴 함.. 

 

그러나 가시성이 훨씬 떨어짐 

 

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

 

 

Doamin

도메인 모델이 존재하는 곳

 

Application 

도메인 모델을 둘러싼 서비스 계층

SendMoneyService는 UseCase를 구현하고, LoadAccountPort와 UpdateAccountStatePort를 사용한다

 

Adapter

애플리케이션의 인커밍 포트를 호출하는 인커밍 어댑터

아웃고잉 포트에 대한 구현을 제공하는 아웃고잉 어뎁터

 

아키텍처 특징

1) 이 패키지에 있는 모든 클래스들은 application 패키지 내에 있는 포트 인터페이스를 통해서만 바깥에서 호출 가능!

2) 어댑터를 다른 구현으로 쉽게 가능하다 (ex. database의 교체)

3) DDD 개념과 직접적인 대응

의존성 주입의 역할

클린 아키텍처의 본질적인 요건은 바로 어플리케이션 계층이 어댑터에 의존하지 않는 것

이를 위해서 controller는 -> use case에 의존하게 구성함,

load account port (인터페이스) 를 통해 의존성을 역전 시켜 account persistence adpater에 의존하지 않게 구성함