이전에 hexagonal 패키지 디자인 패턴에 대해서 아직은 잘 모르겠다던 글이 생각나서 다시 작성한다.
지금은 그때보다는 조금 더 이해 하게 된 편이다.
사용했을때의 장점은 현재의 내가 이해 하기로서는 의존성을 많은 부분 덜어낼 수 있고,
에러가 발생했을때 비교적 빠르게 찾아낼 수 있으며 유지보수성에 큰 도움을 준다 정도 인 것 같다.
// 여기부터는 현재까지 내가 이해한 내용들을 정리 한 것이다.
// 틀린 부분이 있을 수 있으니 혹시나 보시는 분이 있다면 한번 더 찾아보시는 걸 추천..
처음에는 마냥 복잡해 보였는데 직장 동료분의 설명을 듣고 확 와닿았던 것은
adapter 단 과
application 단
domain 단 으로
큰 3가지 단이 있고, 여기에 in,out등이 생기는 구조 인데
이런식으로 보면 가장 편하다.
원래 좀 더 단순한 그림 이었는데
애매한 부분이 있어 동료들에게 물어보다보니 더 복잡해졌다...
보통은 이름이 hexagonal 이라 육각형으로 그리는 경우가 대부분이다.
나같은 경우에는 육각형으로 보면 감을 잡지 못했었는데,
이런식으로 보니 그나마 이해가 갔다.
저 그림에서 포트 인 과 아웃이 위아래로 늘어나면 육각형이 되는 형태 인 것.
내가 '이해하고 사용하는 이유'는 현재로서는 의존성 자체를
꽤많이 줄일수 있는 구조 라는것 정도다.
apdapter in 은 portIn 을 의존하고, portIn은 서비스 기능을 구현한다.
그래서 서비스는 보통 인터페이스로 구성 하고
그래서 어댑터나 포트인 쪽에서 데이터가 꼬이거나 오류가 발생해도
포트아웃쪽으로는 사이드 이펙트가 전파가 되지않는다.
반대로
포트아웃이나 어댑터 아웃에서 필드명이 바뀐다거나
메소드 변경이 생기는 일 이 발생 하더라도,
포트인쪽 까지는 사이드 이펙트가 전파 되지 않는 구조를 지닌다.지금 일하고 있는 회사에서는
좀 더 DDD 아키텍쳐랑 이것저것 섞어서 보완 해서 쓰긴 했지만
사실 이걸 온전히 내가 이해 하고 쓰고 있냐고 한다면 아직은 부족한 것 같다.
헤헤