지나공 : 지식을 나누는 공간
레이어드 아키텍처에 헥사고날 아키텍처 뿌리기 본문
올해 들어 헥사고날 아키텍처 책을 읽었는데 이걸 실무에 당장 도입하기는 쉽지 않다고 생각했다. 패키지 이름도 낯설고 은근 러닝커브(?)가 좀 있는 거 같다. 그래서 이걸 당장 도입하자는 욕심은 잠시 내려놨고, 대신 헥사고날 아키텍처에서 지향하는 것, package-private을 통해 강제하고자 하는 것이 무엇인지 떠올렸다. 최근 팀원 분과 페어프로그래밍을 진행하면서 대부분에게 익숙한 레이어드 아키텍처 안에서도 헥사고날 아키텍처의 지향점을 잘 녹여내자는 목표를 가졌다.
나는 헥사고날을 [만들면서 배우는 클린 아키텍처, 위키북스] 책으로 접했는데, 결국 내내 반복적으로 말하는 지향점은 객체 지향 설계, 즉 SOLID 원칙이었다. 최근에 우리 팀에서 매년 반복적으로 준비하는 행사의 코드가 여기저기 산재되어 있어서 이걸 모듈화하는 작업을 했는데, SOLID 원칙을 녹여내려고 노력했더니 결국 헥사고날 아키텍처에서 말하는 육각형에 매핑되는 클래스들이 나왔다.
그래서 헥사고날 아키텍처 그림 위에 헥사고날 아키텍처에서 말하는 클래스명과 이번 모듈화 때 본 레이어드 아키텍처에서의 클래스명을 각각 윗부분과 아랫부분에 그려봤다.
- 헥사고날 아키텍처 그림 위에 매핑해본 레이어드 아키텍처에서의 클래스명
- 헥사고날 아키텍처에서의 클래스명
- 레이어드 아키텍처에서의 클래스명, 의존 관계 (6개 요소)
매핑은 되지만 확실히 헥사고날처럼 클래스명을 SOLID 원칙이 딱 지켜지게 정하고 패키지도 서로 분리해버리면 SOLID를 더 잘 지킬 수 밖에 없다. 나는 헥사고날 아키텍처가 이런 원칙을 잘 지킬 수 있게 하는 도구라고 느꼈다. 이게 맞는지 아직 확신이 좀 크진 않은데... 보시는 분들 코멘트를 주시면 감사히 읽겠습니다. :) ㅎㅎㅎ
+ gpt에게도 물어봤다.
