01_what_is_wrong_with_layers.md

01. 계층형 아키텍처의 문제는 무엇일까?

• 저자는 일반적인 웹 프로젝트에서 사용하는 계층형 아키텍처에 대해 먼저 설명한다.
• 계층형 아키텍처를 잘 이해하고 구성한다면, 견고한 아키텍처라고 말한다.
• 그럼에도 불구하고, 몇가지 이유로 아키텍처에 문제점이 있다고 말한다. (사실 아키텍처의 문제가 아닌, 개발자의 문제이지만)

1. 데이터베이스 주도 설계를 유도

• 웹 - 도메인(서비스) - 영속성 계층으로 의존성의 방향이 이루어져 자연스레 데이터베이스에 의존하게 된다.
• 비즈니스 관점에서는 도메인 로직을 먼저 만들어야 한다. 그래야 로직을 제대로 이해하는지 확인할 수 있기 때문이다.
• 도메인 로직을 확인한 후에 이를 기반으로 영속성 계층과 웹 계층이 만들어져야 한다.
• 그런데 영속성 계층에 대한 의존성으로 데이터베이스가 먼저 만들어지게 된다.
• 이런 상황은 사실 보통의 웹 프로젝트에서 흔히 일어나지만, 사실 이건 안티 패턴이다.
• 더불어 ORM에서 관리하는 엔티티를 도메인 계층에서 사용하게 되고, 이는 강한 결합을 유도하여 도메인 로직에 다양한 영속성 기능까지 포함하게 된다.
• 이는 JPA 엔티티를 보면 알 수 있다. 온갖 영속성 관련 애노테이션이 붙은 클래스를 마주하게 된다.

2. 지름길을 택하기

• 계층형 아키텍처의 일반적인 규칙은 하위 또는 동일 계층의 컴포넌트에만 접근 가능하다는 점이다.
• 이 외에는 특별한 강제성이 없어 유연함을 제공하는 듯 하지만, 이는 오히려 개발자들에게 안티 패턴을 허용하게 한다.
• 예를 들어,
  • 상위 계층의 컴포넌트를 하위로 내리던지.
  • 중간 계층을 생략하고 접근하게 한다던지.
  • 도메인 로직을 웹 계층에 구현한다던지...
• 이러면 도메인 로직이 여러 계층에 흩어질 수 있다.
• 이렇게 한두명이 하다보면, 점차 설계가 무너지게 된다. (깨진 창문 이론)
• 아마도 이 부분이 계층형 아키텍처의 가장 큰 문제점이 아닐까 한다.

3. 유스케이스를 숨기기

• 이 부분은 조금 새로운 관점인데, 넓은 서비스에 대해서 말하고 있다.
• 넓은 서비스는 무엇일까?
• 유스케이스별 접근이 아닌, 하나의 도메인에 대한 모든 기능을 갖고 있는 서비스를 말하는 듯.
• 이러면 필요한 유스케이스를 찾기도 어렵고, 불필요한 의존성을 가지게 된다.

결론

• 많은 부분에서 공감이 되었다. 실제로 경험한 많은 프로젝트에서 위와 같은 일들이 벌어졌다.
• 이는 사실 개발자의 문제지만, 아키텍처 자체가 많은 것을 용인하기도 하기 때문이다.