카테고리 없음

헥사고날 아키텍처를 사용해야하는 이유?

보리ing 2022. 11. 30. 00:43

현재 대용량이지만 사용자와 트래픽이 많지 않은 빅 데이터 서비스를 개발하고 있다.

새롭게 프로젝트를 만들어감에 따라 프로젝트에 적용할 아키텍처에 대해 고민을 하고 있는데,

도메인의 성격이 나름 구분이 되어 각각의 도메인별 모듈이 나눠지게 되고,

이용자와 트래픽이 많지 않기 때문에 특정 도메인에 필요한 데이터만 많고 나머지는 데이터가 많지 않다.

따라서 모듈은 분리되었으나 DB는 통합된 모놀리식과 MSA의 중간형태인, 멀티 모듈 프로젝트가 만들어진다.

 

아무튼, 이런 배경에서

각 모듈 내부는 헥사고날 아키텍처를 베이스로 하려고 하는데,

헥사고날을 처음 접하고, 아주 심플한 기능을 가진 모듈의 기능을 생각하였을때

헥사고날 아키텍처의 장점은 무엇인가? 꼭 필요한가? 에대 한 고민을 갖게 된다.

 

헥사고날? 요즘 핫하고 뭔가 있어 보이는데 좋은가?

일단 구조가 상대적으로 복잡하고, 서비스를 구현하는데 매번 어댑터를 먼저 정의해야하니 

수많은 보일러 플레이트가 만들어진다.

 

그런데도 사용해?

헥사고날에서 강조하는 부분은

  1. 릭팩토링을 하게 되었을때 검증해야할 부분이 적음
  2. DIP
  3. 3 layer (클린아키텍처)
  4. 명확한 관심사의 분리
  5. 외부와의 연결에 문제가 생기면? 어댑터
  6. 인터페이스? 포트
  7. 프로세서를 변경한다면? 서비스
  8. 비즈니스 로직에 대한 책임은? 도메인
  9. 쉬운 테스트
    1. 자기 역할만 Port 기반 모킹을 통해 테스트(모킹할 부분이 적다)
    2. 비즈니스로직은 의존성이 없기 때문에 모킹이 거의 없다
  10. 객체지향에서 강조하는 DIP와 OCP를 자연스럽게 구현
    1. plugin architecture → hexagonal의 adapter

각 단계의 의존성을 자연스럽게 분리

 

 

이런 내용들이 있는데

 

핵심은 이 아키텍처를 사용하면 자연스럽게 DIP와 OCP를 따르는 코드를 구현하게 된다는 것이다.

 

만드는데의 비용을 3이라면 유지보수 비용을 10이라는 글을 본 적이 있다.

유지보수의 노력을 생각한다면

만들때 다소 번거롭고 복잡하더라도 해볼만하지 않을까?