소리치는 아키텍쳐

아키텍처란 무엇일까? 상황과 범위에 따라 다르겠지만, 애플리케이션을 만들 때 아키텍쳐에 대해 생각해보자.

우선 이 구조를 보고 어떤 애플리케이션인지 파악해보자.

domain 을 보니 이 애플리케이션을 계좌와 관련된 무언가를 하는 것으로 보인다. 
web으로 디렉토리가 빠져있는 것을 보니 delivery 방식은 web을 사용하는 것으로 보인다.
persistence는 domain의 AccountRepository를 구현한 것으로 보인다.

표면적으로 도메인 , 영속성, 딜리버리를 구분해서 크게는 이해해볼 수는 있지만 무엇을 하는지 파악하기는 쉽지 않다. 
즉, 어플리케이션이 어떤 유스케이스들을 제공하는지 파악할 수 없다. 

다른 구조를 살펴보자

이 구조를 보면 계좌와 관련된 것들을 중점적으로 하는 것을 알 수 있다. SendMoneyService 를 통해 돈을 보내는 유스케이스가 있음을 바로 파악할 수 있다. 하지만 이 구조의 문제점은 도메인 코드와 영속성 코드 간의 코드가 같은 패키지에 있어 도메인 코드가 영속성 코드에 의존관계를 가질 수 있는 구조적인 문제가 생긴다.
클린 아키텍쳐에서 말하는 `높은 추상화 수준은 낮은 추상화 수준에 의존하면 안된다` 의 규칙이 위반될 수 있는 가능성이 생긴다.


다음 구조를 살펴보자.

우선 도메인 코드가 영속성 코드에 의존하지 않도록 설계 되었다. 또한, 코드를 보면 어떤 유스케이스들이 있는지 domain 디렉토리 쪽에 다 명시가 되어 있다. 
adapter 쪽에는 web, Spring, persistence 처럼 세부적인 딜리버리 방식과 프레임워크 수준의 코드들이 들어감을 알 수 있다.
어떤 일을 하는 애플리케이션인지 이 구조만 보고도 파악할 수 있다. 
Send Money, Load Account, Update Account State 가 유스케이스임을 한눈에 파악할 수 있다. 처음 이 프로젝트를 여는 순간 `아 돈을 보내는 일을 하는 것이고 계좌를 불러오거나 계좌 상태를 업데이트 하는 일들이 이루어지는구나` 라고 파악할 수 있다.
관심사의 분리가 아주 잘 되어있기 때문에 유지보수의 용이성이 매우 올라간다.
in, out에서 in은 어플리케이션을 주도하는 부분을 의미한다. ui를 눌러서 어플리케이션의 코어 부분을 사용하는 등의 종류들이 이에 속한다.
out은 어플리케이션에 의해 사용되는 부분을 의미한다. 리포지토리와 같은 것들은 수동적으로 사용되기 때문에 out 쪽에 위치시킨다. 

port와 adapter가 사용되어 port-and-adapter architecture 라고 불리며 다른 포스팅(https://bako94.tistory.com/298)에서 정리가 되어있다.


다시 돌아와서, 유스케이스를 바로 파악할 수 있고 높은 추상화 수준이 낮은 추상화 수준에 의존하지 못하도록 할 수 있으며, 관심사의 분리가 잘 이루어져 있기 때문에 이와 같은 아키텍쳐를 고려한다면 생산성 향상에 큰 도움이 될 것이다.