Hexagonal Architecture

Hexagonal Architecture을 프로젝트에 적용하면서 스터디한 내용, 느낀 점을 공유하기 위한 포스트이다.

Hexagonal? Architecture?

먼저 나에게 아키텍쳐는 MVP, MVVM, MVC 만 존재하던 세상이다.
특히, DDD, TDD, Layer는 아예 들어보지도 못한 아키텍처였다.

접하게 된 계기는, 첫 입사 후 서버의 코드의 복잡함, 명확한 로직 구분이 존재하지 않고 서로 엉켜있는 코드 뿐. 스파게티 그 이상의 코드들이 즐비했다.
문제점을 해결하기 위해 서칭을 하니 Architecture 를 적용하는것이 결론으로 나왔고.
회사의 비지니스 로직 상 Hexagonal이 맞다는 판단을 세웠고, Hexagonal을 스터디 하게 시작되었다.

Hexagonal Architeture Definition

Port-Adapter형식으로 의존성이 밖에서 안으로 주어지는 아키텍처이다.
각 계층은 낮은 결합도, 높은 응집도로 이뤄진다.
아키텍처는 4가지의 요소로 이뤄진다.

• Port
  - 데이터가 왔다 갔다하게끔 정의하는 인터페이스
  • 쉽게 열쇠 구멍이라고 생각하면 좋을 것 같다.
• Adapter
  - 인터페이스를 각 포트에 맞추기위한 구성요소
  • 열쇠 구멍에 넣기위해 열쇠를 만드는 곳이라고 생각하면 좋을 것 같다.
• Use Case
  - Port와 Entity를 이어주는 구성요소
  • Port에서 들어오는 요청을 비지니스 로직으로 넣기위한 구성요소라고 생각하면 좋을 것 같다.
• Entity
  - 주 비지니스 로직이 존재하는 곳이라고 생각하자.

글만 봐도 request의 진행방향을 알 수 있을거라 생각한다.
request -> adapter -> port -> usecase -> entity -> usecase -> port -> adapter -> response

이 글을 보는 사람들은 헥사고날 이해가 어려워서 서칭을 하다가 보는 사람들도 있다고 판단해서 조금 힌트를 드린다. 이거 보고 바로 감이 오긴 했다.

• API adapter calls SPI adapter. - Think of HTTP GET requests which end up querying a database: It doesn't make sense to reach database through the domain layer making tons of objects mappings on the way. It's much more efficient for a controller to call the specific SPI port directly.
• SPI adapter calls SPI adapter. - Think of an database adapter which calls other adapters and aggregates all the results before returning it.
• API adapter calls API adapter. - Probably the least useful. Handy, if you need to redirect calls from one API adapter to the other.
• SPI adapter calls API adapter - AVOID. Such calls is unnecessary and creates call loops in the application.
  copyright by Zaur's Thoughts

구현

먼저 참고한 Repo 링크를 올린다.
Zaur's Thoughts

다음 글부터 진행하겠다