**[전통적인 웹 애플리케이션 구조]**
[웹 계층] - 요청을 받아 도메인 혹은 비즈니스 계층에 있는 서비스로 요청을 보낸다.
[서비스 계층] - 서비스에서는 필요한 비즈니스 로직을 수행하고 도메인 엔티티의 현재 상태를 조회하거나 변경하기 위해 영속성 계층의 컴포넌트를 호출한다.
계층형 아키텍처는 견고한 아키텍처 패턴이다.
<aside> 🔥 잘 만들어진 계층형 아키텍처는 선택의 폭을 넓히고, 변화하는 요구사항과 외부 요인에 빠르게 적응할 수 있게 해준다. 엉클 밥에 의하면 이것이 바로 아키텍처의 전부라고 설명하고 있다.
</aside>
글쓴이의 경우 계층형 아키텍처는 코드에 나쁜 습관들이 스며들기 쉽게 만들고 시간이 지날수록 소프트웨어를 점점 더 변경하기 어렵게 만드는 수많은 허점들을 노출한다고 이야기 하고 있다.
3-1 계층형 아키텍처는 데이터베이스 주도 설계를 유도한다.
정의에 따르면 전통적인 계층형 아키텍처의 토대는 DB다.
웹 계층은 도메인 계층에 의존하고, 도메인 계층은 영속성 계층에 의존하기 때문에 자연스레 데이터베이스에 의존하게 되버린다.
즉 모든 것이 영속성 계층을 토대로 만들어진다는 의미를 가지고 있으며 이런 방식은 다양한 문제를 초래할 수 있다.
❓ 문제점을 살펴보기 전 우리가 만드는 애플리케이션의 목적이 무엇인지 한번 생각해볼 필요가 있다.
우리는 보통 비즈니스를 관장하는 규칙이나 정책을 반영한 모델을 만들어서 사용자가 이러한 규칙과 정책을 더욱 편리하게 활용할 수 있게 한다.
이때 우리는 상태(State)가 아니라 행동(behavior)을 중심으로 모델링한다. 상태를 바꾸는 것은 행동이기 때문에 행동이 비즈니스를 이끌어 간다.
❓ 우리는 왜 “도메인 로직”이 아닌 “데이터베이스”를 토대로 아키텍처를 만드는 것일까?
보통 애플리케이션의 유즈케이스를 떠올릴 때 보통 데이터베이스의 구조를 먼저 생각하고 이를 토대로 도메인 로직을 구현하는게 대부분이다.
이는 전통적인 계층형 아키텍처에서는 합리적인 방법이다. 의존성의 방향에 따라 자연스럽게 구현한 것이기 때문이다. 하지만 비즈니스 관점에서는 전혀 맞지 않는 방법이다.
다른 무엇보다도 도메인 로직을 먼저 만들어야 한다. 그래야만 우리가 로직을 제대로 이해했는지 확인할 수 있다. 그리고 그 도메인 로직이 맞다는 것을 확인한 후에 이를 기반으로 영속성 계층과 웹 계층을 만들어야한다.
❓ 데이터베이스 중심적인 아키텍처가 만들어지는 큰 원인은 무엇일까?
가장 큰 원인은 바로 ORM 프레임워크를 사용하기 때문이다. ORM 프레임워크를 계층형 아키텍처와 결합하면 비즈니스 규칙을 영속성 관점과 섞고싶은 유혹을 쉽게 받게된다.
위의 그림처럼 ORM에 의해 관리되는 엔티티들은 일반적으로 영속성 계층에 두게 된다. 계층은 아래 방향으로만 접근이 가능하기 때문에 도메인 계층에서는 이러한 엔티티에 접근할 수 있다.
하지만 이렇게 되면 영속성 계층과 도메인 계층 사이에 강한 결합이 생기고 만다. 서비스는 영속성 모델을 비즈니스 모델처럼 사용하고 이로 인해 도메인 로직뿐만 아니라 즉시로딩, 지연로딩, 트랜잭션, 캐시 플러시 등 영속성 계층과 관련된 작업을 해야만한다.
영속성 코드가 사실상 도메인 코드에 녹아들어가 둘 중 하나만 바꾸는 것이 어려워진다. 이는 유연하고 선택의 폭을 넓혀준다던 계층형 아키텍처의 목표와 정확히 반대되는 상황이다.