본문 바로가기

사이드프로젝트/(240808)이거왜오름?

이거왜오름? 헥사고날 리팩터링

할까말까 했는데,이럴때나 해보지 언제해보겠어 싶어서 헥사고날로 리팩터링을 하기로 했음

 

핵사고날의 핵심은 의존성역전이고(클린아키텍처가 다그렇긴하지만),외부와 내부의 분리가 핵심임

나는 기본전략으로는 jpa엔티티와 도메인엔티티의 분리는 하지않을거고,컨트롤러입력모델과 도메인엔티티는 따로 둘거임,단 레포트의 경우 jpa엔티티와 도메인엔티티를 분리할거임

또한 어플리케이션단에서는 도메인을 그냥 사용할예정

즉 인포트의 입력모델과 출력모델만 있고,나머지는 다 도메인을 직접사용함

 

기본구성은 각 도메인(도메인보다 좀 더 큰 애그리거트라고 하는게 맞겠지만)마다 패키지를 두고

이런식으로 분리하고,어댑터는 포트를 구현하고,

인포트는 유스케이스,아웃포트에는 레포지토리인터페이스,api포트인터페이스 등이 들어갈예정임

이런식으로 어댑터 패키지가 어플리케이션 패키지를 의존하고,어플리케이션 패키지는 어댑터 패키지에 의존하지않는    형태가 나오는게 헥사고날의 핵심임

 

또한 하나로 묶여있는 유스케이스와 레포지토리 인터페이스를 각각 분해할거임(응집도높게)

 

추가적으로 신경써야할건,기존에 있었던 포트인터페이스를 만약 여러곳에서 사용해야한다면,각 도메인별로 각각 포트   인터페이스를 만들고,어댑터는 해당 인터페이스들을 모두 구현해야함

그냥 간단하게 인터페이스복붙한다음에 클래스명만 바꿔주면됨(어짜피 메서드의 메시지가 같으면 인터페이스구현에는 똑같이들아가니까)

이때 인터페이스는 해당 유스케이스가 사용할것만 남기고 나머지는 지워주는게 좋음(인터페이스 최소 원칙)

 

대충

이런식이 됨(in을 input로 바꿨음,코틀린 패키지에서 in은 예약어라 사용할수없어서)

 

이런식으로 모든 도메인에 걸쳐서 이동작업을 일단 해주면 1차는 끝임

 

 

솔직히 구조야 크게 중요하지않고,제일 중요한건 의존성 관리임

밖에서 안을 의존하고,의존할떄도 중간 인터페이스를 양쪽이 의존하고,안은 절대 밖을 의존해선 안됨