만들면서 배우는 클린아키텍처_역자 서문 & 추천사

• 역자 서문 & 추천사
  • 계층형 아키텍처 VS 헥사고날 아키텍처
    • 계층형-아키텍처
    • 헥사고날 아키텍처
  • 포트와 어댑터
  • 실무적으로 헥사고날 아키텍처를 적용하기 어려운 이유

---

역자 서문 & 추천사

Get your hands dirty on clean architecture 원서를 재밌게 읽었는데,
이 책의 번역서가 출간되어 팀원분들과 함께 스터디를 진행하며 읽기 시작했다.

이 책은 지금 회사에 입사해서 읽고 직접 헥사고날 아키텍처로 설계된 서비스를 이해하고 직접 적용하면서 개발 방향에 많은 영향을 준 책이기에, 1년 반이 지난 지금 시점에 읽으면 처음 읽었을때와 다르게 다가오지 않을까 기대가 된다.

특히 팀원분들과 조영호님의 추천사를 읽으면서 감탄과 전율을 느꼈다는 분들이 많았다.
그만큼 조영호님의 아키텍처에 대한 내공이 느껴졌고, 핵심을 이렇게 언어로 풀어낼 수 있다는 점이 인상적이었다.

계층형 아키텍처 VS 헥사고날 아키텍처

p13

육각형 아키텍처는 모든 외부 요소를 근본적으로 외부 인터페이스로 나타내므로 비대칭 계층화 체계와는 다른 모양의 대칭 뷰를 보여준다.

전통적인 계층형 아키텍처는 … 따라서 도메인 계층 입장에서 의존성은 비대칭적입니다.

반면 육각형 아키텍처에서는… 따라서 도메인 계층의 입장에서 의존성은 대칭적입니다.

계층형 아키텍처

프레젠테이션 계층은 하위의 도메인 계층에 의존하고, 도메인 계층은 하위의 영속성 계층에 의존한다.

헥사고날 아키텍처

도메인은 상대적으로 가장 변화가 없어야 한다.
DB는 변경 가능성이 도메인에 비해 크다고 본다.
헥사고날 아키텍처에서 도메인은 프레젠테이션 계층과 영속화 계층의 존재를 알 수 없다.
프레젠테이션 계층과 영속화 계층이 도메인에 의존하는 이 구간을 의존성 역전을 위해 Port와 Adapter로 인터페이싱한다.

	계층형(레이어드) 아키텍처	헥사고날 아키텍처
의존성의 방향	비대칭	대칭
DB를 교체하거나 쿼리가 변경될 경우, 도메인 코드 변경 여부	도메인 코드도 변경해야 한다.(도메인이 DB를 의존하고 있기 때문)	도메인 코드를 변경할 필요가 없다.(이유: 영속화 계층이 도메인 계층을 의존하기 때문)
계층 간의 경계와 의존성 강제 여부	계층 간의 경계와 의존성을 강제할 수 없다. (개발자들이 계층을 나누는 것을 규칙으로 개발하지만, 강제되는 것은 아님)	계층 간의 경계와 의존성을 강제할 수 없다.(효과: 도메인에 대한 보호를 확실하게 할 수 있다.)

---

포트와 어댑터

p14

육각형 아키텍처에서 애플리케이션은 비즈니스 관심사를 다루는 내부(inside)와 기술적인 관심사를 다루는 외부(outside)로 분해됩니다. 여기서 외부에 포함된 기술적인 컴포넌트를 어댑터(adapter)라고 부르고, 어댑터가 내부와 상호작용하는 접점을 포트(port)라고 부릅니다.

육각형 아키텍처 패턴을 포트와 어댑터 패턴이라고 부르는 이유가 바로 이 때문입니다.

---

실무적으로 헥사고날 아키텍처를 적용하기 어려운 이유

헥사고날 아키텍처를 실무적으로 적용할 때 모순이 있는 부분들을 경험할 수 있다.

• 도메인 라이브러리에서 외부 라이브러리를 사용할 수 없다.
• ‘도메인 레이어에서 값에 대한 유효성 검증을 어떻게 할 것인가?’에 대한 고민
• ‘프레젠테이션 계층의 필드와 도메인 레이어 필드의 필드명이 다른 경우, 어떻게 매핑할 것인가?’에 대한 고민

반드시 헥사고날을 사용해야 한다기보다는 개방 폐쇄 원칙을 지키고, 실무에 접목하며 사용하는 게 좋을 것 같다.
책 내용이 모두 정답은 아니므로 비판적으로 읽으며, 현실적으로 적용 가능한지도 고민하며 읽어보자.