한달에 포스팅 1개의 목표는 아직 지켜지고 있던(7월 기준 7개) 중에, 지원한 회사에 최종 합격을 하게 되었다. 전 직장도 물론 아주 만족하며 다니고 있었지만 뭐에 홀린듯(?) 지원을 하게 되었고, 최종 합격까지 오게 되었다. 합격하기 까지의 과정과 회고는 나중에 따로 정리해볼 생각이다. 물론 이 경험과 그때의 감정을 잊기전에 최대한 빨리......!
사내에서는 헥사고날 아키텍처라는게 요즘 이슈인듯하다. 마침 팀에서 하는 프로젝트에 헥사고날 아키텍처를 적용하게되면서 따로 스터디도 진행하고 어느정도 프로젝트가 진행되고 있었다. 이제 막 팀에 들어온 나로써는 얼른 적응해야지! 라는 생각을 가지고 있었고, 마침 해당 아키텍처를 적용한 프로젝트에 참여하게 되어, 잠시 놓고 있었던 자기계발을 다시 시작해야겠다 생각했다. 관련 책 몇 권을 추천 받았고, 그중에 만들면서 배우는 클린 아키텍처라는 책을 먼저 보게 되었다. 일단 책이 좀 얇았고.......! 빠르게 훓고가자는 생각으로 시작하게 되었다.
책의 순서대로 정리를 하기 보다는 여러번 읽다가 하나씩 글을 남겨볼 생각이다. 물론 모든 내용이 남지 않을 수도 있을 것 같지만, 그냥 다 써내려가는 것 보다는 조금 더 의미가 있을 것이라 생각이된다.
헥사고날 아키텍처
헥사고날 아키텍처는 육각형 아키텍처라고 볼 수 있다.
헥사고날 아키텍처에 항상 거론되는 이미지이다. Adapter, Input, Output, Usecase, Entity 크게 5개의 분류로 되어 있는데, 처음에 그림만 봐서는 무슨말인지 잘 몰랐다. 심지어 그림을 보고 코드를 봐도 이해하기 힘들었다.
핵심은 단일 책임 원칙과 의존성 역전 원칙인 것 같다. 단일 책임 원칙은 하나의 객체는 하나의 기능만을 수행해야하는 것을 의미하며 이는 변경의 이유는 오직 하나뿐이라는 것을 의미하며, 의존성 역전 원칙은 저수준 모듈의 의존하는게 아닌 고수준 모듈 즉, 구현된 클래스가 아닌 상위 인터페이스에 의존해야 한다는 것을 의미한다.
UseCase 사용으로 인해서 예를들어 기존의 UserService에 관련된 모든 비즈니스로직을 구현함으로 써 엄청나게 많은 비즈니스 로직이 하나의 클래스파일에 있었다면, RegisterUserUseCase, DeleteUserUseCase, UpdateUserUseCase 와 같이 세부적으로 나누면서 여러가지 책임을 가지고 있던 UserService를 단일 책임을 맡도록 여러개의 UseCase로 나눌 수 있게 된다.
또한, 가장 안쪽에 있는 도메인(Entity)는 어떠한 의존성도 없어야한다. 그래서 다른 계층에서의 변경에 영향을 받지 않으며, 유일한 변경 이유는 비즈니스 요구사항의 변경이 되야 한다. JPA를 사용한다고 했을 때, @Entity 또한 외부에 의존성을 가지고 있는 것이기 때문에 그림상에 있는 Entity 부분에는 알맞지 않는 것 같다. 그래서 PersistenceAdapter 부분에 영속성을 가지고 그부분에서 JPA Entity를 가져야하며, 해당 Entity와 도메인간의 Mapper가 필요할 듯 하다.
결국 실제로 구현을 해봐야 이해가 더 빠를 것 같다. 충분한 개념과 지식이 없는 상태로 중간에 프로젝트에 투입이 되었지만, 끝날 무렵에는 어느정도 헥사고날 아키텍처에 대해서 익숙해져 있기를.....