왜 계층형 아키텍처로는 충분하지 않은가

계층형 아키텍처란?

웹 -> 도메인 -> 영속성 계층으로 구성된 전통적인 웹 애플리케이션 구조를 3계층 아키텍처라고 한다. 

1. 웹 계층에서는 요청을 받는다.

2. 그 요청을 도메인 계층에 있는 서비스로 보내서 비즈니스 로직을 수행한다.

3. 도메인 엔티티의 조회 및 저장을 위해서 영속성 계층을 호출한다.

 

이 계층형 아키텍처는 굉장히 전통적인 형식이다. 전통적이라는 것은 오랜 시간에 걸쳐 장점을 인정받고 살아남았다는 뜻이다. 계층형 아키텍처는 각 계층에 독립적으로 로직을 작성할 수 있는 견고함을 가진다는 장점이 있다. 하지만 이 계층형 아키텍처의 문제점은 바로 변화에 대응하기 어려운 소프트웨어가 될 수 있다는 것이다.

 

데이터베이스에 의존성이 높다는 것

애플리케이션의 존재 목적은 비즈니스의 규칙과 정책을 반영한 모델의 구축과 구현이다. 그리고 이렇게 만들어진 애플리케이션은 사용자의 행동에 의해 작동된다. 즉 비즈니스를 이끌어가는 것은 특정 '상태'가 아니라 사용자의 '행동'인 것이다. 하지만 데이터베이스는 상태를 저장하는 것이고, 행동을 중심으로 구성되지 않는다. (SQL, NoSQL이 아니라 Neo4J 같은 Graph Database 의 경우 조금 다르게 생각해볼 수도 있는 것 같지만...) 어쨌든, 그렇기 때문에 한계가 있는 것이다.

우리는 먼저 도메인 로직을 만들고 이 로직이 맞다는 것을 확인하고 나서 이것을 기반으로 영속성 계층과 웹 계층을 고려해야 한다.

 

유즈케이스가 코드 속에 파묻혀버렸다

서비스는 영속성 계층에 많은 의존성을 갖게 되고, 웹 계층은 이 서비스에 의존하게 된다. 그러면, 서비스 자체를 테스트하기도 어려워지고 (의존하는 영속성 계층의 컴포넌트가 많기 때문에), 서비스에서도 작업해야 할 지점을 찾는 것이 어려워진다.

 

동료는 1 PR을 올렸을 뿐인데, 충돌이 난다

하나의 서비스에서 너무 많은 일들을 처리하게 되면, 역할 분리가 제대로 되지 않았다는 뜻이다. 앞서 본 것처럼 SRP도 잘 지켜지지 않았다. 그러면, 동료와 동시 작업이 어려워진다. 데이터베이스 중심의 설계는 영속성 로직이 도메인 로직과 섞여 있기 때문에, 동료의 코드와 충돌이 날 가능성이 매우 높다.

 

참고한 책

• 만들면서 배우는 클린 아키텍처 - 자바 코드로 구현하는 클린 웹 애플리케이션 (톰 홈버그 지음 / 박소은 옮김 / 조영호 감수)