계층형 아키텍쳐의 문제는 문제일까?

계층형 아키텍쳐란?

계층으로 구성된 어플리케이션은 일반적인 3계층 아키텍처를 포함한다.

웹 계층, 도메인 계층, 영속성 계층으로 구성된 적통적인 웹 어플리케이션 구조

웹 계층에서는 요청을 받아 도메인 혹은 비즈니스 계층에 있는 서비스로 요청을 보낸다. 서비스에서는 필요한 비즈니스 로직을 수행하고, 도메인 엔티티의 현재 상태를 조회하거나 변경하기 위해 영속성 계층의 컴포넌트를 호출한다. 

 

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

1. 계층형 아키텍처는 데이터베이스 주도 설계를 유도한다.

 전통적인 계층형 아키텍처의 토대는 데이터베이스이다. 웹 계층은 도메인 계층에 의존하고, 도메인 계층은 영속성 계층에 의존하기 때문에 자연스레 데이터베이스에 의존하게 된다. 하지만 대부분의 어플리케이션의 목적은 규칙이나 정책을 반영한 모델을 만들어서 사용자가 이러한 규칙과 정책을 더욱 편리하게 활용 할 수 있게 한다. 이때 상태가 아니라 행동을 중심으로 모델링한다. 

 ORM기반의 프레임워크는 영속성의 관점과 섞어 서비스를 만들기 때문이다. 계층형 아키텍처는 아래방향으로만 접근을 하기 때문에 서비스에 영속성 코드가 필요하고 강한결합이 생긴다. 따라서 영속성 계층과 도메인 계층 사이에 둘 중 하나만 바꾸는 것이 어려워진다.

 

2. 지름길을 택하기 쉬워진다.

계층형 아키텍처에서 전체적으로 적용되는 유일한 규칙은 특정한 계층에서는 같은 계층에 있는 컴포넌트나 아래에 있는 계층에만 접근가능하다는 것이다. 따라서 상위 계층에 위치한 컴포넌트에 접근해야 한다면 간단하게 컴포넌트 계층을 아래로 내려버린다.

결국 맨 영속성 계층은 비대해진다. '지름길 모드'를 끄고 싶다면, 빌드가 되지 않도록 강제해야 한다.

 

3. 테스트하기 어려워진다.

계층형 아키텍처의 일반적으로 나타나는 변화는 계층을 건너뛰는 것이다.

계층을 건너뛰게 되면 2가지 문제점이 발생한다. 첫 번째 문제는 단 하나의 필드를 조작하는 것에 불과하더라도 도메인 로직을 웹 계층에 구현해야 한다. 앞으로 유스케이스가 발생하면 더 많은 도메인 로직을 웹 계층에 추가해서 어플리케이션 전반에 걸쳐 책임이 섞이고 핵심 도메인 로직들이 퍼져나갈 확률이 높다.

 

두 번째는 웹 계층 테스트에서 도메인 계층뿐만 아니라 영속성 계층도 모킹해야 한다. 단위 테스트 복잡도가 올라간다. 규모가 커지면 다양한 영속성 컴포넌트에 의존성이 많이 쌓이면서 테스트의 복잡도를 높인다. 어느 순간에는 실제로 테스트 코드를 작성하는 것보다 종속성을 이해하고 목(Mock)을 만드는 데 더 많은 시간이 걸리게 된다.

 

4. 유스케이스를 숨긴다.

개발자들은 새로운 유스케이스를 구현하는 새로운 코드를 짜는 것을 선호한다. 기능을 추가하거나 변경할 적절한 위치를 찾는 일이 빈번하기 때문에 아키텍처는 코드를 빠르게 탐색하는 데 도움이 돼야 한다. 이런 관점에서 계층형 아키텍처는 어떻게 우리의 발목을 잡을까?

계층형 아키텍처는 도메인 서비스의 너비에 관한 규칙을 강제하지 않는다. 넓은 서비스 계층은 영속성 계층에 의존성을 갖게 되고 다시 웹 레이어의 많은 컴포넌트가 이 서비스에 의존하게 된다. 테스트하기도 어려워지고 작업해야 할 유스케이스를 책임지는 서비스를 찾기도 어려워진다.