인프런 커뮤니티 질문&답변
작성한 질문수
의존성 방향과 관련된 질문이 있습니다.
해결된 질문
작성
·
375
0
안녕하세요 토비님.
OrderRepository 인터페이스가 application layer에 있고,
이걸 구현한 구현체가 persistence layer에 있는데요.
일반적인 layered 아키텍처라고 하면, 의존성의 방향이 아래로 향해야하는데, 이 경우라면 의존성이 application 으로 향하게 되는거 같은데요.
만약에 이런식으로 구성한다면 port & adapter 같은 개념을 별도로 두지 않더라도, 의존성방향에 의하면 헥사고날 (혹은 클린 아키텍처) 라고 부를 수 있는건가요? 아니면 그럼에도 layered 아키텍처라고 부르나요?
답변 2
3
외부 세상과 내부 애플리케이션으로 구분하고 외부에서 내부로만 의존하게 하고 그 경계에 인터페이스(ports)를 두는 방식을 헥사고널이라고 하고, 그걸 이용해서 아키텍처를 설명한 것으로 클린 아키텍처가 있습니다.
이런 아키텍처는 그림을 보통 원형으로 그리죠.
반면 보통 레이어 아키텍처라고 하는 건 수직으로 레이어를 나누고 의존 방향성을 아래로 향하게 합니다.
그런데 당장 DIP만 적용해도 의존 방향성이(실제 호출이 일어나는 런타임 의존은 여전히 아래지만) 위로 올라가기도 하고, 이때 중심이 되는 레이어가 보통 헥사고널에서 애플리케이션이라고 부르는 영역이죠.
저는 기술 서비스의 인터페이스를 애플리케이션 레이어에 두고 구현체를 아래에 두는 경우, 코드의 의존 방향성이 위로 올라가게 되더라도 이건 레이어 아키텍처라고 부를 수 있다고 생각합니다. 이걸 좌우로 펼치고 원을 그리면 헥사고널이라고 부를 수도 있고요.
헥사고널/클린 아키텍처와 레이어 아키텍처는 서로 상충되지 않습니다. 헥사고널 아키텍처도 따져보면 레이어 아키텍처의 원칙을 잘 지키는 구조입니다.
이게 설명이 길어져서 제가 강의에서 다루지는 않았는데 다음 강의에서 기회가 되면 자세히 설명드리고 싶네요.
굳이 레이어 아키텍처의 방향성이 중요하다고 보면, 퍼시스턴스 레이어를 제일 위로, 보통 프레젠테이션 계층이라고 하는 옆이나 위로 올려보세요. 그러면 레이어 아키텍처에서 친숙했던, 각각 독립된 책임을 가진 계층이면서 의존 방향은 아래로만 향하는 그림이 되겠죠. 여기서 의존관계를 잘 지키면서 원형으로 다시 배치해보면 친숙한 클린 아키텍처 그림이 됩니다.
Implementing Domain Driven Design이라는 책의 4장에서도 DIP를 설명하면서 이와 같은 레이어 아키텍처 그림을 그려줍니다. 인프라스트럭처 레이어를 가장 위로 올리거든요. 관심 있으면 찾아보세요.
기회가 되면 이에 대해서 자세히 다루는 강의나 영상을 만들어보겠습니다.
참, 질문은 뭐라고 불러야 하냐는 것이었군요. 그냥 DIP가 적용된 레이어 아키텍처라고 하셔도 되고, 포트&어댑터, 헥사고널, 클린.. 뭐라고 부르셔도 좋습니다. 안에 도메인/엔티티까지 의존 방향을 중심으로 향하도록 한다면요.
0
음.. 클린 아키텍처 책에서는 의존성의 방향으로 레이어드 아키텍처와 구분을 하고 있어서 조금 혼동스럽습니다.
인터페이스를 통해 DIP 를 적용해서 외부의 의존성들을 제거한다면 실질적으로 어플리케이션(혹은 비즈니스) 레이어에서는 기술에 대한 세부 정보를 알 수 없기에, 레이어드 아키텍처로 부를 수 없지 않나라고 생각하는데요.
토비님께서는 레이어드 아키텍처를 위와 같은 정의(의존성 방향을 중심으로 이해하는)가 아니라, 계층간 응집(?) 혹은 책임이 다른 구현체들 간의 격리를 중점적으로 생각하시는거라고 이해하면 될까요?
추가로 토비님이 언급해주신 반 버논의 DDD 책을 잠시 보았는데요. 아마 제가 언급한 레이어드 아키텍처는 책에서 설명하는 전통적인 레이어드 아키텍처에 대해 말씀드린거 같습니다.
정리하자면, 토비님의 말씀은 어쨋든 DIP 를 이용한 아키텍처(전통적인 레이어드 아키텍처는 아니지만 레이어가 나뉘어진) 육각형 모양으로 반전시키면 헥사고날 아키텍처가 된다. 라고 이해하면 될까요?
일반적으로 레이어드 아키텍처와 대비해서 클린 아키텍처나 헥사고널을 설명한다는 것은 알고 있습니다.
제가 생각하는 레이어드 아키텍처는 Layers Architectural Pattern이라고 설명된 것을 말합니다. 큰 시스템은 작은 서브 시스템으로 분해되어 각각 응집력이 있는 책임을 가진 모듈로 나뉘고, 그리고 바로 자기 아래 계층에만 의존해야 한다는 것이죠. 여기서 Relaxed Layered System이라는 변형도 소개되는데 방향만 아래쪽으로 향하고 있다면 자기 바로 아래 있는 시스템에만 의존하지 않고 더 아래 레이어를 의존해도 됩니다.
제가 이해하는 계층형 아키텍처는 이것인데, 이걸 전통적인 프레젠테이션-비즈니스로직-인프라스트럭처라는 고정된 순서를 계층으로 만든 것만을 레이어드 아키텍처라고 본다면 DIP를 적용하는 순간 코드 레벨의 의존관계는 계층형이 아닌 것이 되죠. 그런데 그렇게 협소한 의미로 레이어드 아키텍처를 제한해서 다뤄야할 이유를 모르겠습니다.
그래서 저는 반 버논의 책에 나온대로 DIP를 적용한 후에도 여전히 독립적인 계층으로 분리되어있고, 자기 아래쪽의 계층에 의존하는 구조로 나뉘어져 있는 것은 레이어드 아키텍처라고 부를 수 있다고 생각합니다.
단지 원형으로 그리고 방향을 가운데로 몰았다거나, 아니면 좌우 대칭으로 만들었다거나 해서 헥사고널이나 클린 아키텍처라는 레이어드 아키텍처가 아닌 다른 것이라고 설명하는 것에는, 뭐 충분히 그렇게 접근할 수도 있다고 보지만, 동의하지 않습니다.
클린 아키텍처에서도 여전히 계층으로 구분하는 것이 중요하고 계층간 의존 관계가 중요하기는 마찬가지일테니까요. 그리고 그 방향성은 원형을 직선으로 풀어놓고 보면 한쪽으로만 흐르게 되어있고요.
전통적인 3계층 아키텍처를 원형으로 그리는 그림도 있습니다. PoEAA에 나오는 서비스 레이어 설명의 그림이 그렇죠.
물론 이렇게 이야기하면 설명이 복잡하고, 이런식의 설명을 하는 사람은 아직 반 버논과 조영호 님 밖에 못 보긴했습니다.
그러면 전통적인 J2EE 3 Tier Layered Architecture 같은데다 DIP를 적용하고 나면 뭐라고 불러야 할까요?