언제 실제로 육각형 아키텍처 스타일을 사용해야 할까? 그리고 언제 육각형 아키텍처 스타일 대신 전통적인 계층형 아키텍처 스타일(or 이외)을 고수해야 할까?

12.1. 도메인이 왕이다.

영속성 관심사나 외부 시스템에 대한 의존성 등의 변화로부터 자유롭게 도메인 코드를 개발할 수 있는 것이 육각형 아키텍처 스타일의 주요 특징이라는 점이 명확해졌다.

<aside> 💡

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

</aside>

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

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

만약 도메인 코드가 애플리케이션에서 가장 중요한 것이 아니라면 이 아키텍처 스타일은 필요하지 않을 것이다.

12.2. 경험이 여왕이다.

인간은 습관의 동물이다. 습관이 저절로 결정을 내리기 때문에 우리는 무언가를 결정할 때 시간을 들일 필요가 없다. 만약 새로운 웹 애플리케이션을 만든다면 계층형 아키텍처 스타일을 이용한다. (습관이 되어버림)

나쁜 결정은 아니다. 습관이 나쁜 결정을 내릴 때만큼, 좋은 결정을 내릴 때도 도움이 된다. 과거에 했던 일에 편안함을 느끼는데 무언가를 바꿔야 할 이유는 없다. 따라서 아키텍처 스타일에 대해 괜찮은 결정을 내리는 유일한 방법은 다른 아키텍처 스타일을 경험해 보는 것이다. 육각형 아키텍처에 대한 확신이 없다면 애플리케이션의 작은 모듈부터 시작해보자. 익숙해지자.

12.3. 그때그때 다르다.

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