🏴󠁩󠁤󠁪󠁷󠁿Facts(한 것) & Findings(배운 것)

최근 프로젝트를 진행하면서 계층형이 굉장히 테스트하기 힘들다는 생각과

특히 서비스 혹은 컨트롤러에 여러 도메인이 의존하고 있을 때 그 하위 로직을 작성하기 정말 힘들다는 생각이 들었다.

그래서 집에 있는 <만들면서 배우는 클린아키텍처> 라는 책을 펴니 첫 장에 계층형 아키텍처의 문제점에 대해 설명하고 있었고,

나는 이것이 오늘 나에게 줄 가장 큰 교훈이라고 생각했다. 그래서 계층형 아키텍처와 그 문제에 대해서 살펴보려 한다.

나는 면접에서 계층형 아키텍처에 관한 질문을 받기 전까지 계층형 아키텍처가 가장 효율적인 설계라는 편협한 생각을 가지고 있었다.

그렇게 생각한 이유는 다음과 같다.

나를 포함한 여러 사람들이 계층형 아키텍처를 좋아하는 이유는 '관심사의 분리'라고 생각한다. ~~(아님 말고)~~

관심사의 분리는 소프트웨어 설계 측면에서 유지보수에 아주 용이하기 때문에 관심사 분리가 좋다는 것에는 당연히 이견이 없다.

하지만 관심사를 분리시키는 것이 계층형 뿐일까? 만약 그렇지 않다면 계층형을 고집해야할까?

계층형의 문제가 뭘까?

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

생각해보면 당연한 말인거 같다.

웹 계층은 도메인 계층에 의존하고, 도메인 계층은 영속성 계층에 의존하기 때문에 자연스러운 흐름대로라면 데이터베이스에 의존하게 된다.

우리는 어떤 애플리케이션을 설계할 때 행동을 중심으로 모델링을 하는데, 이 과정에서 도메인 로직이 아닌 데이터베이스를 토대로 아키텍처를 만들게 된다.

그럼 왜 DB를 토대로 아키텍처를 만들까?

이는 자연스러운 의존성 방향 때문이다. 데이터베이스의 방향으로 의존하고 있기 때문에 그런 것이다.

그리고 책에서는 ORM을 사용하기 때문이라고 말한다.

ORM에 의해 관리되는 엔티티들은 일반적으로 영속성 계층에 두는데,

이때 계층은 아래 방향으로만 접근이 가능하기 때문에 도메인 계층에서는 이러한 엔티티에 접근할 수 있다.

그리고 엔티티에 접근할 수 있다면 분명히 사용되기 마련이다.

이렇게 되면 도메인 계층과 영속성 계층 사이에 강한 결합이 생겨서 서비스는 영속성 모델을 비지니스 모델처럼 사용하게 되고,

이때문에 즉시로딩, 지연로딩, DB 트랜젝션, 캐시 플러시 등등 영속성 계층과 관련된 작업들을 해야만 한다.

이 외에도 책에서 소개하는 계층형의 단점들이 있다.

"지름길을 택하기 쉬워진다.", "테스트하기 어려워진다", "유스케이스를 숨긴다", "동시작업이 어려워진다" 등 다양한 문제점을 안고있다.

나는 몇주에 걸쳐서 문제를 해결하고, 점차 Hexagonal로 나아갈 예정이다.

🏴󠁩󠁤󠁪󠁷󠁿Affirmation(자기선언)