[책 리뷰] 만들면서 배우는 클린 아키텍처

통근 시간 중 20분 정도 지하철에 앉아있는 시간이 있어서 책을 읽어야겠다는 생각을 했다.

 

줄곧 클린 아키텍처에 대한 전문가 분들의 이야기가 궁금했고 만들면서 배우는 클린 아키텍처가 140쪽 분량의 들고 다니면서 읽기 좋겠다고 생각해서 이 책으로 결정했다.(+ 주변 동료들의 추천)

우선 개인적으로 많은 책을 읽어보진 않았지만 책에서 하고자 하는 이야기가 "효과적인 객체 지향 프로그래밍 방법" 을 알려주는 명서들과 어느 정도 비슷하다는 느낌을 받았다. (-> 유연하고 유지보수가 용이한 아키텍처를 설계하고 코드를 작성하는 것)

 

책에서는 기존의 단방향 계층형 아키텍처의 문제점을 개선한 육각형 아키텍처에 대해 설명하고 실제 코드로 설계하는 방법에 대해서 알려주는데 시스템 설계에서 가장 핵심이 되는 도메인 로직을 외부로부터 분리하고 의존 관계가 외부로부터 도메인으로 향할 수 있도록 코드를 작성해야함을 강조하고 있다.

 

육각형 아키텍처

책을 읽다보면 "원래 이렇게 개발하고 있었는데?" 하는 순간이 있을 수 있다. 사실 우리는 이미 온라인의 많은 레퍼런스에서 이러한 클린 아키텍처 모델을 사용하고, Spring MVC 방식으로 개발한다면 Spring Data JPA 에서 제공하는 JPARepository 인터페이스(추상화)에 Service 가 의존하는 의존 역전 원칙을 자연스럽게 사용하고 있었을 수 있다.

 

하지만

1. 왜 육각형 아키텍처 패턴으로 개발해야 하는지

2. 계층 간 데이터를 어떻게 주고 받는게 좋은지 (+ 의존 관계는 어떻게 설계하면 좋을지)

3. 도메인 중심의 설계가 어떤 것을 의미하는지

에 대해서 본인만의 명확한 기준이 존재하지 않는다면 꼭 읽어 보면 좋을 책이라고 생각한다.

 

---

짧은 정리

용어

책에서는 클린 아키텍처를 구현하기 위해 (입/출력)포트와 어댑터 그리고 유스케이스 라는 용어를 사용한다.

 

처음에는 다소 어색한 용어일 수 있는데 특별한 것은 아니고 도메인을 중심으로,

유스케이스는 MVC 모델에서 Service 로 생각할 수 있고

입력 포트는 유스케이스의 인터페이스

출력 포트는 외부 시스템을 사용하기 위한 인터페이스(eg. Repository)

어댑터는 외부 계층에서의 구현체 정도로 생각할 수 있다.

 

아래 사진의 계층 간 의존 관계에 집중해서 보면 조금 더 이해하기 쉬울 것이다.

 

 

 

도메인이 변경을 주도하다

도메인 영역은 비즈니스 로직이 구현된 영역이다. 다시 말해, 도메인 요구사항이 변경되지 않는 이상 도메인 영역의 코드가 변경되지 않아야 함을 이야기한다.

 

그렇기 때문에 보통 도메인 영역의 Service(책에서는 Use Case) 에서 의존하는 영속성 객체를 구현체가 아닌 추상화(책에서는 Output Port) 에 의존(의존 역전 원칙) 하라고 이야기 한다.

 

도메인이 변경을 주도해야 한다는 것은 계층 간 어떤 데이터를 교환해야 할지에 대한 것과도 관련이 있다. 가령 Controller 에서 Service 를 호출하는데, 그 반환값이 Controller 가 사용하기에 편하도록 설계가 된다면 나중에 Controller 코드가 변경될 때 Service 로직까지 수정될 위험이 있다. (= Service 가 Controller 에 강하게 결합된다)

-> 반대(?)로 영속성 계층의 반환값은 도메인 영역에서 원하는 값으로 설정한다. (도메인 요구사항이 변경되어 영속성 계층의 변경이 생기는 것은 자연스럽기 때문에)

 

따라서, 도메인 계층의 인터페이스를 더 작은 단위로 세분화(+ 반환값을 최대한 단순히) 하고 외부 계층(= Controller) 에서 도메인 로직을 조립해서 사용할 수 있도록 유도한다. 또한, 각 계층 별로 전용 모델(eg. DTO) 을 가지고 각 계층이 의존하는 전용 모델을 생성할 책임을 가질 때 계층 간 설계의 유연성을 증가시킬 수도 있다.

 

정답은 없다 그때 그때 다르다

유연함과 복잡함은 trade off 관계다. 유연한 아키텍처를 설계할 수록 관리의 복잡도(팀원 전체가 클린 아키텍처에 대한 이해도가 높아야 한다)가 늘어날 수 있다. 반면 여러 지름길(eg. Controller 에서 Repository 의존하기, 구현체 의존하기, 공유 모델을 파라미터, 반환값으로 사용하기 등등) 을 택한다면 유연성은 조금 떨어져도 빠른 시간 안에 코드를 작성할 수 있다.

 

---

마무리

위에서 간단하게 정리한 내용 외에도 책에서는 계층 간 매핑 전략, 패키지 관리 방법, 테스트 방법, 상황 별로 선택할 수 있는 여러 지름길들 등 더 자세하게 설명해준다.

 

책 마무리로 정답은 없고, 그때 그때 개발자가 상황에 맞는 클린 아키텍처를 적용하라는 것은 책의 밑밥(?)인가 할 수 있지만, 개인적으로는 주어진 요구사항(및 환경적 요건) 내에서 얼마나 효과적으로 객체지향 프로그래밍을 할 수 있을까를 끊임없이 되묻고 팀원들과 소통해 합의된 아키텍처를 구성해 나가는 능력을 강조하는 것이 아닌가 하는 생각이 든다.

 

아직 실무에서 코드를 작성하진 않았지만 이 책을 읽으면서 코드 작성 간 여러 트레이드 오프를 고려할 수 있는 개발자로 성장하는 것이 중요하다는 것을 다시금 깨달을 수 있었다. 앞으로 작성하는 코드 퀄리티를 높이는데 이 책이 꼭 도움이 되었으면 좋겠다!