헥사고날 아키텍쳐에 대한 고찰?

헥사고날 아키택쳐란

클린 아키텍쳐의 일종으로 Adapter와 Port를 통해서 내부 비즈니스로직이 외부의 영향을 받지 않도하고 항상 저수준 모듈이 고수준 모듈에 의존하게 하는 아키텍쳐이다. 

즉 개발자는 외부 infra에 상관없지 비즈니스 로직만 잘 짜면 되는 관심의 분리를 높이고 응집도를 높이는 아키텍쳐이다.

 

구현

Adpater를 통해 Request가 들어오면 해당 Adapter는 Port를 호출하고 Port의 구현체인 비즈니스 로직이 핵심 로직을 처리한다.

또한 비즈니스 로직에서 외부 API나 DB를 호출할때역시 Port를 통해 호출하고 Apdater를 통해 나간다.

Domain을 분리하고 DIP를 통해 외부와의 결합을 떨어뜨리고 외부의 변화가 내부에 영향을 미치지 않도록 한다.

 

고민

근데 고민인게 
이것 또한 결국 잘 만들어진 Layerd Architecture를 통해서 구현가능 한것 아닌가? 
라는 생각이 든다.

Controller, Service, Database를 잘 추상화 해서 사용한다면 Service 구현체 또한 비즈니스 로직에 집중할 수 있을 것이고, 변경에도 충분히 유연하게 대처할 수 있을 거라고 생각한다. 

 

좀 더 공부한 후 왜 굳이 헥사고날을 사용하는지에 대한 명확한 이유에 대해 한번 더 정리할 필요가 있는 것 같다..

 

음 헥사고날은 방향이 무조건 Adapter -> Port -> Bussiness Model -> Port -> Adpater 라는 강제성이 있다. 라는 장점 이있긴 한 것 같다.

레이어드는 이러한 강제성이 없이 여차하면 respository에 service 로직이 들어 갈 수도 있고 Controller에 특정 로직이 들어갈 수도 있는 것..

하지만 정교하게 잘 작성된 레이어드 아키텍쳐 정확하게 규칙을 사용하면 밀릴것은 없다고 생각이든다. 
하지만 개발은 혼자하는게 아니고 개발에 대한 유지보수를 위해서는 헥사고날 아키텍쳐의 강제성이 필요할 것 같다는 생각도 든다.

 

아키텍처 방향성

아키텍쳐를 설정할때 항상 애매하고 이게 맞는 것인지 확인하기 힘들다.

그래서 몇가지 기준을 제시한다.

1. 필요한 시스템을 만들고 유지보수하는 데 투입되는 인력 최소화에 유리한가? 

2. 소스 코드 의존성이 안쪽으로, 고수준 정책을 향하고 있는가?

3. 세부 사항이 변경되어도 도메인(핵심 규칙)에 변경이 없을 것인가?
4. 테스트하기 쉬운가?

5. 아키텍처 원칙들을 잘 지키고있는가?

 

Real-World

아키텍처에 대해서 공부하면서 가장 와닿은 말이 있다.

아키텍처는 방안의 수납장, 서재와 같은 것들이다.

방에 수많은 물품들이 있고 이것들을 정리하기 위해선 수납장, 서재와 같은 것들이 필요할 것이다.

하지만 물품들이 별로 없고 손쉽게 관리할 수 있다면 수납장이 필요없을 것이다.

소프트웨어는 항상 현실세계를 따라가려고한다.

이러한 예시를 통해 필요한 아키텍쳐를 잘 선택하면 될 것 같다. 

 

 

크게 도움된 컨퍼런스이다.

https://www.youtube.com/watch?v=g6Tg6_qpIVc