[클린 아키텍처] 계층형 아키텍처(Layered Architecture)의 문제는 무엇일까?

ChatGPT가 그린 클린 아키텍처

 

일반적인 3계층 아키텍쳐(전형적인 웹 애플리케이션 구조)

: 웹 → 도메인 → 영속성

계층형 아키텍처의 문제점은 무엇일까? 코드에 나쁜 습관들이 스며들기 쉽게 만들고 시간이 지날수록 소프트웨어를 점점 더 변경하기 어렵게 만드는 수많은 허점들을 노출한다.

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

정의에 따르면 전통적인 계층형 아키텍처의 토대는 데이터베이스이다.

웹 계층은 도메인 계층에 의존하고, 도메인 계층은 영속성 계층에 의존하기 때문에 자연스레 데이터베이스에 의존하게된다.

우리는 보통 비즈니스를 관장하는 규칙이나 정책을 반영한 모델을 만들어서 사용자가 이러한 규칙과 정책을 더욱 편리하게 활용할 수 있게 한다. 이때 우리는 상태(state)가 아니라 행동(behavior)을 중심으로 모델링한다. 어떤 애플리케이션이든 상태가 중요한 요소이긴 하지만 행동이 상태를 바꾸는 주체이기 때문에 행동이 비즈니스를 이끌어간다.

 

 

💡 다른 무엇보다도 도메인 로직을 먼저 만들어야 한다. 그래야만 우리가 로직을 제대로 이해했는지 확인할 수 있다. 그리고 도메인 로직이 맞다는 것을 확인한 후에 이를 기반으로 영속성 계층과 웹 계층을 만들어야 한다

 

ORM 프레임워크를 계층형 아키텍처와 결합하면 비즈니스 규칙을 영속성 관점과 섞고 싶은 유혹을 쉽게 받는다.

ORM에 의해 관리되는 엔티티들은 일반적으로 영속성 계층에 둔다. 하지만, 이렇게 되면 영속성 계층과 도메인 계층 사이에 강한 결합이 생긴다. 서비스는 영속성 모델을 비즈니스 모델처럼 사용하게 되고 이로 인해 도메인 로직뿐만 아니라 즉시로딩/지연로딩, 데이터베이스 트랜잭션, 캐시 플러시 등등 영속성 계층과 관련된 작업을 해야만 한다.

 

지름길을 택하기 쉬워진다

전통적인 계층형 아키텍처에서 전체적으로 적용되는 유일한 규칙은, 특정한 계층에서는 같은 계층에 있는 컴포넌트나 아래에 있는 계층에만 접근 가능하다는 것이다.

 

💡 강제한다 → 해당 규칙이 깨졌을 때 빌드가 실패하도록 만드는 규칙

 

 

테스트하기 어려워진다

• 엔티티의 필드를 단 하나만 조작하면 되는 경우에 웹 계층에서 바로 영속성 계층에 접근하면 도메인 계층을 건드릴 필요가 없지 않을까?

→ 두 가지 문제점

• 도메인 로직을 웹 계층에 구현하게 된다 → 프로젝트가 커질수록 핵심 도메인 로직들이 퍼져나갈 확률이 높다
• 웹 계층 테스트에서 도메인 계층 뿐만 아니라 영속성 계층도 모킹해야 한다. 이렇게 되면 단위 테스트의 복잡도가 올라간다. → 복잡한 설정을 할 시간이 없기 때문에 테스트를 작성하지 않는 방향으로 가는 첫걸음이다.

 

유스케이스를 숨긴다

기능을 추가하거나 변경할 적절한 위치를 찾는 일이 빈번하기 때문에 아키텍처는 코드를 빠르게 탐색하는데 도움이 돼야 한다.

 

고도로 특화된 좁은 도메인 서비스가 유스케이스 하나씩만 담당하게 한다면 이런 작업들이 얼마나 수월해질까? UserService에서 사용자 등록 유스케이스를 찾는 대신 RegisterUserService를 바로 열어서 작업을 시작하는 것처럼 말이다.

 

동시 작업이 어려워진다.

레이어드 아키텍처의 경우 서로 다른 기능을 동시에 작업하기 더욱 어렵다. 서로 다른 유스케이스에 대한 작업을 하게 되면 같은 서비스를 동시에 편집하는 상황이 발생하고, 이는 병합 충돌과 잠재적으로 이전 코드로 되돌려야 하는 문제를 야기하기 때문이다.

 

유지보수 가능한 소프트웨어를 만드는 데 어떻게 도움이 될까?

올바르게 구축하고 몇 가지 추가적인 규칙들을 적용하면 레이어드 아키텍처는 유지보수하기 매우 쉬워지며 코드를 쉽게 변경하거나 추가할 수 있게 된다. 그러나, 레이어드 아키텍처는 많은 것들이 잘못된 방향으로 흘러가도록 용인한다.