프로젝트 아키텍처와 의존성 방향 다이어그램

이번 프로젝트는 멀티 모듈환경에서 헥사고날 아키텍처를 적용하여 구성해 보았다.

모듈과 클래스의 의존성 방향 다이어그램은 아래와 같다.

 

 

이처럼 헥사고날 아키텍처로 프로젝트를 구성해보니 MVC 아키텍처와 비교했을 때, 장단점이 확실하게 보였다.

 

장점은 비즈니스 로직, 도메인이 UI, Infra(세부사항)를 모른다는 것과 세부사항이 비즈니스 로직의 플러그인이 된다는 것이다. 이는 세부사항이 결정되지 않은 시점에도 비즈니스 핵심 로직을 구현할 수 있다. 세부사항이 자주 변경되거나 아직 결정되지 않은 시점에 헥사고날 아키텍처를 도입하면 생산성이 증가할 것이라고 생각한다.

 

하지만 단점또한 명확하다. 아직 헥사고날 아키텍처의 디렉터리 구조에 익숙하지 않다는 점을 감안하더라도 패키지 구조가 복잡하다. MVC 아키텍처와 비교했을 때 단순 디렉터리의 개수만해도 확연하게 차이가 있고, 기능 구현에도 비교적 많은 시간이 소요된다.

 

또한 각 계층에서 사용하는 데이터 모델이 분리되어 있다보니, 빈번한 객체 변환이 필요하다.

예를 들어 위의 그림에서 Actor가 브라우저를 통해 특정 데이터를 포함한 요청과 이를 응답하는 과정에서의 객체 변환을 살펴보면 다음과 같다. bootstrap 모듈의 RequestDto는  Domain 객체로 변환되어 application 모듈과의 경계를 횡단한다. framework 모듈에서는 application 모듈에서 넘어온 Domain 객체를 Entity 객체로 변환하여 DB persistence 작업을 수행한다. 

이제 응답도 동일한 객체 변환 과정을 거친다. Entity를 Domain으로 변경하여 application 모듈로 전달되고 이는 후가공을 거치거나 혹은 그대로 bootstrap 모듈로 전달된다. bootstrap 모듈에서는 이를 ResponseDto로 변환하여 응답한다. 

 

이러한 작업에서 발생하는 객체 변환 메서드의 양은 적지 않다고 생각한다. 개인적으로 이런 보일러 플레이트 코드를 계속해서 작성하는 것은 리소스 낭비라고 생각한다. 따라서 보통 mapper 라이브러리를  사용하여 해결한다고 하니 프로젝트에 적용해보려 한다.

 

지금 마주한 문제는 각 유스케이스에 대해 VO를 두어 유스케이스(1) : VO(1) 매핑을 유지하는 꼴을 가져갈지, 여러 유스케이스가 Domain 객체의 필요한 데이터만 초기화하여 사용하는 꼴을 가져갈지(필요하지 않은 프로퍼티는 nullable 하다)에 대한 문제이다. 해당 부분은 아직 도메인에 대한 개념이 부족하다고 생각하여 추후 도메인 주도 개발 도서를 참고하여 해결해보려 한다.

 

사실 지금 진행중인 프로젝트 규모와 상황에 헥사고날 아키텍처는 적합하지 않다고 생각한다. DB, UI, 인프라가 거의 다 정해져있고, 실제로 개발할 기능의 규모도 작기 때문에 오버 엔지니어링이라고 생각한다. 하지만 지금은 배우는 입장이기에 아키텍처의 이해와 적응을 목표로 헥사고날 아키텍처를 사용하고자 한다.