계층형 아키텍처를 사용하는 나쁜 예

계층형 아키텍처로 프로젝트를 구성하다 보면 모든 것을 영속성 계층을 토대로 만들기 쉽다. 도메인 로직을 먼저 구현하고 영속성 계층을 구현하기 보다는 데이터베이스의 구조를 먼저 생각하고 이를 토대로 도메인 로직을 구현하게 된다.

ORM을 사용하다 보면 비즈니스 규칙을 영속성 관점과 섞고 싶은 유혹을 쉽게 받게 된다. 이렇게 되면 각 서비스는 영속성 모델을 마치 비즈니스 모델처럼 사용하게 되고 도메인 로직 뿐 아니라 eager loading, lazy loading, 트랜젝션, 캐시 플러시 등 영속성 작업이 서비스에 포함되기도 한다.

영속성 코드가 도메인 로직과 분리되지 않으면, 코드의 변ㄱ셩이 어려워진다.

이런 일이 발생하는 원인

클린 아키텍처처럼 계층형 아키텍처를 사용하면 특정 계층에서는 같은 계층이나 그보다 아래에 있는 계층에만 접근 가능하다. 따라서 만약 하위 계층에서 상위 계층에 접근해야 한다면, 하위 계층에 상위 계층에 들어가야할 로직을 옮겨 넣고 싶은 유혹에 빠진다.

발생 가능한 문제1: 계층을 건너뛰는 코드

간단하게 DB에서 값 하나만 바꾸면 되는 경우, 컨트롤러에서 서비스 계층을 거치지 않고 바로 repository를 이용하고 싶은 유혹에 빠질 수 있다.

이렇게 될 경우,

• 도메인 로직이 웹 계층(controller)에 구현된다
• 테스트 복잡도가 올라가 테스트하기 어려워진다.

발생 가능한 문제2: 유즈케이스를 찾기 어려워진다

기능을 추가하거나 변경할 위치를 찾아야 할 때, 아키텍처는 수정해야할 곳을 빠르게 찾는데 도움이 돼야 한다. 하지만 도메인 로직이 혼재되어 있거나 하나의 유즈케이스가 너무 비대해지면, 이런 작업은 매우 어려워 진다.

• 계층형 아키텍처에서는 도메인 로직이 여러 계층에 걸쳐 흩어지기 쉽다.
• 여러개의 유즈케이스를 담당하는 하나의 거대한 서비스가 만들어지기도 한다.

발생 가능한 문제3: 동시 작업이 어렵다

모든 것이 영속성 계층을 기반으로 설계되기 때문에, 한명은 영속성 계층을, 한명은 도메인 계층을, 한명은 웹 계층을 맡아 개발할 수 없고, 한 명이 영속성부터 시작해 차례로 도메인, 웹을 만들게 된다.

• 데이터베이스 주도 설계는 영속성 로직과 도메인 로직이 분리되지 않아 각 측면을 분리해 개발하기 어렵다.