클린 아키텍처란 무엇인가, 계층형 아키텍처의 문제점과 함정

 

 

일반적인 계층형 아키텍처

계층형 아키텍처의 흐름은 간단하게 설명하면

1. 웹 계층에서 클라이언트 요청을 받습니다.
2. 요청을 받아 도메인 혹은 비즈니스 계층에 있는 서비스로 요청을 전달합니다.
   • 서비스 계층에서 필요한 비즈니스 로직을 수행합니다.
3. 도메인 엔티티의 현재 상태를 조회하거나 변경하기 위해 영속성 계층의 컴포넌트를 호출합니다.

위에서 설명했듯이, 웹에서 도메인 그리고 영속성 방향으로 요청이 흘러감을 알 수 있습니다.

 

여기서 생기는 문제점이 있습니다.

 

자연스럽게 웹 계층은 도메인 계층에 의존하게 되고, 도메인 계층은 영속성 계층에 의존하게 되어, 결론적으로 데이터베이스에 의존하게 되는 문제가 발생합니다.

 

이것이 왜 문제가 되냐면,

애플리케이션의 목적은 비즈니스를 관장하는 규칙이나 정책을 반영한 모델을 만들어서 사용자가 해당 서비스를 편리하게 활용할 수 있도록 하는 것이 목적이다.

→ 그래서 우리는 (데이터) 상태가 아니라 (비즈니스) 행동을 중심으로 모델링해야 합니다.
애플리케이션에서 상태가 중요한 요소이긴 하지만 행동이 상태를 바꾸는 주체이기 때문에 행위를 중심적으로 개발해야 합니다.

 

기존 계층형 아키텍처에서는 의존성의 방향에 따라 자연스럽게 영속성 계층부터 구현을 진행했을 것이다.

(왜냐하면 조회하는 쿼리에 맞게 도메인 클래스를 생성하고, DTO를 만들어 요청에 응답했기 때문에)

 

도메인 계층과 영속성 계층의 강한 결합

계층형 아키텍처 구조로 프로젝트를 진행하면 보통 엔티티들을 영속성 계층에 둡니다.

의존성의 방향에 따라 도메인 계층의 서비스는 아래 방향에 있는 엔티티에 접근할 수 있습니다.

이렇게 흘러가면 서비스는 엔티티를 비즈니스 모델처럼 사용하게 되어 도메인 로직과 영속성 계층을 한 클래스 파일에 관리되는 문제점이 생깁니다.

 

• 비즈니스 상태와 로직을 분리하여 관리하기 어렵다.
• 데이터베이스와 관련된 작업이 섞여 코드를 관리하기 어렵다.

 

엔티티 무작위 사용으로 인한 테스트 어려움

계층형 아키텍처를 사용하면서 최악으로 변화는 형태는 엔티티의 필드만 접근하면 되어 웹 계층에서 바로 영속성 계층에 접근하는 것입니다.

1. 단 하나의 필드를 조작하는 것에 불과하더라도 도메인 로직을 웹 계층에 구현하게 됩니다.
   • 유스케이스가 확장된다면 웹 계층과 도메인 계층 간의 책임이 섞이는 문제가 발생한다.
2. 웹 계층 테스트에서 도메인 계층 뿐만 아니라 영속성 계층도 모킹해야 하는 문제가 생긴다.
   • 즉, 다른 계층도 모킹해야 되는 단위 테스트 작업에 번거로움이 생깁니다.

 

유스케이스를 파악하기 어렵다.

개발자는 새로운 프로젝트에 들어가기도 하지만, 기존 프로젝트 코드를 리팩터링 하는 작업도 많이 진행합니다.

새로운 작업에 들어가는 것이 아니면 기존의 유스케이스를 파악한 다음에 코드를 수정해야 하므로, 아키텍처 코드를 빠르게 탐색할 수 있는 점이 중요합니다.

 

계층형 아키텍처는 편의에 따라 도메인 로직이 여러 계층에 흩어지기 쉬운 문제가 있습니다.

1. 유스케이스가 간단해서 도메인 계층을 생략하여 웹 계층에 존재하는 경우
2. 도메인 계층과 영속성 계층 모두에서 접근할 수 있도록 특정 도메인 클래스를 영속성 계층으로 내린 경우

위와 같은 구조는 협업을 하는데 있어 기존 코드를 파악하는데 어려움을 유발합니다.

 

도메인 서비스 너비의 관한 문제

서비스가 여러 웹 계층과 영속성 계층과 연관될 수 있습니다.

 

넓은 서비스는 영속성 계층에 많은 의존성을 가지면서, 웹 계층의 많은 컴포넌트를 해당 서비스에서 의존하게 됩니다.

• 해당 서비스를 테스트하는데 어려워지고, 유스케이스를 책임지는 서비스를 찾기 어려워집니다.
• 또한, 협업을 진행하면서 하나의 서비스에 여러 기능을 동시에 작업하여 Merge Conflict가 발생할 확률이 높아집니다.

---

어떤 아키텍처를 사용하든, 해당 아키텍처의 함정을 염두에 두고 도메인 중심적으로 모델링하여 좁은 도메인 서비스를 가져가는 것이 좋은 것 같다고 느꼈다.
더불어, 개발팀에서 시간 문제와 편의를 위해 하나둘씩 지름길을 택한다면 나중에 유지보수하거나 유스케이스를 확장하는데 어려움으로 이어져 더 많은 수정이 발생할 거라 느껴졌다.

 

 

만들면서 배우는 클린 아키텍처 - 예스24