계층형 아키텍처의 문제점
계층형 아키텍처 그림
- 웹 - 도메인 - 영속성
데이터베이스 중심의 설계를 유도한다
계층형 아키텍처에서 웹 계층을 도메인 계층에 의존하고, 도메인 계층은 영속성 계층에 의존합니다. 결국 자연스럽게 데이터베이스에 의존하게 됩니다. 데이터베이스 중심의 개발은 사용자의 행위보다는 상태에 더 집중하게 만듭니다. ‘계정이 잠기면 이런 저런 행위를 하지 못한다.(행위)’ 보다 ‘계정의 상태가 LOCKED 일 때에는 이런 저런 행위를 하지 못한다.’ 라는 생각을 하면서 개발을 하게 됩니다. LOCKED라는 계정의 상태가 데이터베이스에 저장되어 있음을 인지하고 떠올리면서 개발해야하는 것의 차이를 말하고 싶었습니다.
ORM을 사용할 때, 도메인 계층에서 영속성을 고려하게 된다
JPA와 같은 ORM에서 관리되는 엔티티들은 일반적으로 영속성 계층에 존재합니다. 그리고 엔티티 클래스를 열어보면 객체 중심의 개발이라는 의도를 가지고 비즈니스 관련 로직들이 엔티티 클래스에 포함되어 있습니다. 그리고 이러한 엔티티 클래스를 도메인 계층에서 사용합니다. 영속성 계층에 존재하는 엔티티를 도메인 계층에서 사용하고 있기 때문에, 도메인 계층에서도 즉시로딩/ 지연로딩, 데이터베이스 트랜잭션, 캐시 플러시 등을 고려하면서 개발하게 됩니다.
애매한 패키지와 클래스는 영속성 계층에 추가하게 된다
영속성 계층에 존재하는 클래스는 모든 계층에서 접근할 수 있습니다. 그래서 역할이 애매한 클래스들은 모두 영속성 계층에 추가하게 되는 현상이 발생합니다. 그러면 영속성 계층은 점점 넓어지고 무거워집니다.
유스케이스를 숨기고 테스트하기 어려워진다
새로운 기능을 추가하거나 기존 기능의 정책을 변경할 때는 기존 기능들을 파악하고 영향도를 점검하는 것에서부터 시작합니다. 그런데 도메인 또는 영속성 계층으로만 구분되어 있다면, 하나의 계층에 너무 많은 클래스들이 포함되어 있어서, 지금 내가 찾아봐야하는 클래스가 어디에 속해있는지 파악하기 어렵게 됩니다. 이렇게 되면 비슷한 역할을 하는 클래스가 곳곳에 숨어있게 되고, 몇 달 뒤에 그 기능을 사용해야할 때 비슷한 역할을 하는 클래스 중 어떤 클래스를 사용해야하는지 헷갈리게 됩니다. 목적에 맞는 클래스를 찾는 것이 먼저인지, 테스트 코드를 작성하기 어려운 것이 먼저인지는 모르겠지만 결국에는 유즈케이스를 찾아서 테스트 코드를 추가하기가 어려워집니다. 하나의 클래스에 비슷한 이름의 수많은 클래스들이 주입되어 있기 때문입니다.
'DEV > Architecture' 카테고리의 다른 글
헥사고날 아키텍처 시리즈 6. 영속성 계층 (0) | 2024.03.16 |
---|---|
헥사고날 아키텍처 시리즈 5. 애플리케이션 계층 (0) | 2024.03.16 |
헥사고날 아키텍처 시리즈 4. 패키지 구조 (0) | 2024.03.15 |
헥사고날 아키텍처 시리즈 3. 헥사고날 아키텍처 시작하기 (0) | 2024.03.14 |
헥사고날 아키텍처 시리즈 2. 계층형 아키텍처 극복하기 (1) | 2024.03.14 |