[만들면서 배우는 클린 아키텍처] 12. 아키텍처 스타일 결정하기

만들면서 배우는 클린 아키텍처 책을 읽고 정리하며 소감을 적는 포스트입니다.

 

서론

---

지금까지 헥사고날 스타일로 웹 애플리케이션을 만드는 방법을 설명했다. 어떤 부분들은 전통적인 계층형 아키텍처 스타일에도 적용할 수 있다. 또 어떤 부분들은 도메인 중심의 접근법에서만 구현 가능하다.

 

그렇다면 실제로 언제 헥사고날 아키텍처 스타일을 사용해야 할까? 그리고 언제 헥사고날 대신 기존 아키텍처를 고수해야 할까?

 

도메인이 왕이다.

---

지금까지 살펴본 내용을 통해 영속성 관심사나 외부 시스템에 대한 의존성 등의 변화로부터 자유롭게 도메인 코드를 개발할 수 있는 것이 헥사고날 아키텍처 스타일의 주요 특징이다.

 

 

외부의 영향을 받지 않고 도메인 코드를 자유롭게 발전시킬 수 있다는 것은 헥사고날 아키텍처 스타일이 내세우는 가장 중요한 가치다.

 

이것이 헥사고날 아키텍처 스타일이 도메인 주도 설계 방식과 정말 잘 어울리는 이유다. 당연한 말이지만 DDD에서는 도메인이 개발을 주도

한다. 그리고 영속성 문제나 다른 기술적인 측면에 대해서 함께 생각할 필요가 없게 되면 도메인에 대해 가장 잘 고려할 수 있게 된다.

 

헥사고날 스타일과 같은 도메인 중심의 아키텍처 스타일은 DDD의 조력자라고까지 말할 수 있다. 도메인을 중심에 두는 아키텍처 없이는, 또 도메인 코드를 향한 의존성을 역전시키지 않고서는, DDD를 제대로 할 가능성이 없다. 즉, 설계가 항상 다른 요소들에 의해 주도되고 말 것이다.

 

그래서 헥사고날 아키텍처를 사용할지 말지를 결정할 첫 번째 지표로서, 만약 도메인 코드가 애플리케이션에서 가장 중요한 것이 아니라면 이 아키텍처 스타일은 필요하지 않을 것이다.

 

경험이 여왕이다.

---

인간은 습관의 동물이다. 습관이 저절로 결정을 내리기 때문에 우리는 무언가를 결정할 때 시간을 들일 필요가 없다. 만약 새로운 웹 애플리케이션을 만든다면 계층형 아키텍처 스타일을 이용한다. 과거에 자주 이렇게 해왔고, 습관이 된 것이다.

 

이것이 반드시 나쁜 결정이라는 것은 아니다. 우리가 과거에 했던 일에 편안함을 느끼는데 무언가를 바꿔야 할 이유가 있을까? 따라서 아키텍처 스타일에 대해서 괜찮은 결정을 내리는 유일한 방법은 다른 아키텍처 스타일을 경험해 보는 것이다.

 

헥사고날 아키텍처에 대한 확신이 없다면 지금 만들고 있는 애플리케이션의 작은 모듈에 먼저 시도해 보자. 개념에 익숙해지고 스타일에 익숙해져 보자. 아이디어들은 적용하고, 수정하고, 자신만의 아이디어를 추가해서 편하게 느껴지는 스타일을 개발해 보자

 

그러면 이 경험이 다음 아키텍처 결정을 이끌어 줄 것이다.

 

그때그때 다르다

 

---

어떤 아키텍처 스타일을 골라야 하는가에 대한 대답은 “그때그때 달라요” 와 같다. 어떤 소프트웨어를 만드느냐에 따라서도 다르고, 도메인 코드의 역할에 따라서도 다르다. 팀의 경험에 따라서도 다르다. 그리고 최종적으로 내린 결정이 마음에 드느냐에 따라서도 다르다.

 

끝으로..

---

계층형 아키텍처를 구성하며 느껴왔던 데이터베이스 주도 설계에 대한 부분과 경계가 모호한 점 등 여러 가지 느껴왔던 부분들을 해당 책을 읽으면서 명확하게 다시 한번 느낄 수 있었다.

 

특히 굉장히 구체적으로 책이 서술되어 있어 좋았고 도메인 주도 개발을 하기 위해 의존성을 역전시켜 도메인을 외부의 영향을 받지 않도록 하는 핵심적인 가치를 반복적으로 꺼내주어 강력하게 인식할 수 있었다.

 

돌이켜보면 가장 감명 깊게 읽었던 챕터는 ‘8장 경곗값 매핑하기’인 것 같다. 굉장히 현실적인 챕터라고 생각이 들었고 저렇게 다양한 매핑 전략이 존재한다는 것도 알게 되었다. (특히 단방향 전략)

경곗값 매핑하기는 가장 현실적인 문제인 것 같다. 경곗값마다 매핑 모델을 따로 두는 것이 좋은 것임을 알면서도 현실적으로 같은 모델에 매핑만 하는 경우가 많아 의미가 있는 부분인가 하는 생각에 평소에 많이 헤매고 있었는데, 그 이유는 바로 하나의 매핑 전략을 전역적으로 사용해야 한다는 생각이 가장 큰 원인이었던 것 같다.

 

앞으로는 헥사고날 아키텍처를 기반으로 DDD의 대해 더 알아보고자 한다.