계층형 아키텍처는 왜 데이터베이스 중심의 설계를 유도할까?

1. 계층형 아키텍처가 어때서?

마틴 파울러의 책, PoEAA (Pattern of Enterprise Application Architecture: 엔터프라이즈 애플리케이션 아키텍처 패턴)을 보면 대표적인 3 계층을 소개하는 파트가 있다. 이름도 그 흔한, 3-tire-아키텍처, 또는 계층형 아키텍처 등 부르는 이름도 은근 다양하다.

 

 

이러한 아키텍처를 사용하던 방식을 잠시 떠올려보면...

최상단의 표현 계층이 도메인(서비스) 계층에 의존하고, 다시 도메인 계층은 영속성 계층에 의존하게 된다.

사용자 요청의 시작을 기점으로 생각해보면 이러한 흐름은 자연스럽게 데이터베이스에 의존하게 된다.

 

개발자가 의식하지 못한 사이에 어느덧 도메인 계층의 코드들이 영속성 계층을 기반으로 만들어지게 된다.....

이쯤 돼서 다음과 같은 주제를 한번 생각해 보자.

 

우리의 애플리케이션의 목적이 무엇일까?

 

비즈니스 적으로 중요한 문제를 모델을 만들어 해결하고, 이렇게 해결된 문제가 사용자에게 편리함을 제공할 수 있게 된다.

 

이때 우리는 state(상태)가 아니라 behavior(행동)을 중심으로 모델링한다.

어떤 애플리케이션이든 상태가 중요한 요소이긴 하지만 행동이 상태를 바꾸는 주체이기 때문에 행동이 해당 애플리케이션을 이끌어간다 할 수 있다.

 

기존에 자주 적용해 보던 UserStory기반의 ATDD 방식만 떠올려 봐도, 사용자의 행동을 중심으로 상태를 변경하게 되는 비즈니스 모델을 만들기 다반수였다. 행동이 상태를 바꿔주는 주체이기 때문이다.

 

그동안 나의 개발 방식을 회상해 보면 다음과 같다.

1. ERD를 작성한 후 Entity모델을 먼저 만든다
2. 인수테스트 작성 후
3. 표현 계층을 구현한다
4. 도메인 계층 구현
5. 영속성 계층 구현

나의 경험상 도메인 로직이 항상 거의 마지막쯤에 만들어졌다. (다행히 완전 마지막은 아닌!!)

이는 전통적인 계층형 아키텍처에서는 당연하고 손쉬운 방식의 접근이다. 하지만 비즈니스를 최후에 고려하는 것이 적합할까?

아니다, 비즈니스 관점에서는 적합하지 않은 방식이다. 가장 먼저 도메인 로직을 작성한 후에 나머지를 처리해야 한다.

도메인 로직에 대한 작성 또는 이해 없이 만들어진 Entity나 표현 계층이 안전할까?

 

이 글을 읽는 당신 또한 스스로 생각해 보자! 그간 영속성 계층을 먼저 구현했는가? 아니면 도메인 로직을 먼저 구현했는가?

아마도? 데이터베이스과 ORM을 생각한 후에 도메인을 구현하였을 것이다.

 

도메인 로직이 적합함을 판단한 후에 이를 기반으로 표현계층과 영속성 계층을 구현해야 한다.

 

2. 현실은...

하지만 현실적으로 Spring, JPA에 의존적으로 개발을 진행해 오던 나의 방식을 다시 한번 회상해 보자.

항상 Entity부터 떠올린 주범은 누굴까? 아마도 ORM 프레임워크의 사용이 한몫을 해준다 생각한다.

 

예전에 나 또한 ORM을 사용해 오면서 비즈니스 로직을 만들며, 다양한 영속화와 관련된 기술을 사용했다. (사실 이 자체가 큰 문제는 아니라 생각된다)

 

다만 다음 그림을 생각해 보자. 보톤 내가 하는 프로젝트 대부분이 아래와 같은 구조이다.

도메인 영역에서 Entity에 접근할 수 있기 때문에 당연하게 사용된다. "접근"자체가 가능하기 때문에 이는 사용으로 직결된다.

 

하지만 이는 영속성 계층과 도메인 계층 사이에 강한 결합을 만들어낸다. service가 repository를 비즈니스 모델처럼 다양하게 메서드를 만들어 사용하게 되고, 이로 인하여 도메인뿐만 아니라, Lazy, Eager loading, 트랜잭션, cache, 기타 등등 영속화를 위한 작업을 기본적으로 해주어야 한다.

 

이처럼 영속성 기술들이 도메인 코드상에 침투하기 시작하면, 점점 변경에 어렵고 유연성이 떨어지게 된다.

 

아키텍처란 흔히 말하는 SOLID 원칙을 달 준수할 수 있도록 도우며, 특히 추가와 확장성에 열려있어야 하지 않을까?