1장 - 계층형 아키텍처의 문제는 무엇일까?

계층형 아키텍처는 애플리케이션의 스케일이 작거나, 개발 시작하기 무난한 아키텍처로 선택받기도 한다.

예전부터 많이 선택되어 왔고 지금도 레거시 기술 스택을 사용하는 회사라면, 계층형 아키텍처로 많이 개발을 한다.  

계층형 아키텍처

계층형 아키텍처는 견고한 아키텍처 패턴이다. 계층을 잘 이해하고 구성한다면 웹 계층이나 영속성 계층에 독립적으로 도메인 로직을 작성할 수 있다. 도메인 로직에 영향을 주지 않고 웹 계층이나 영속성 계층의 기술을 변경할 수 있다. 

 

하지만 현재에 이르러서는 계층형 아키텍처 때문에 문제가 생기는 곳이 많고 각종 책에서는 계층형 아키텍처의 문제점을 언급하고 비권장하기도 한다. 

왜 계층형 아키텍처가 문제가 되었는지 알아보자.

---

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

계층형 아키텍처에서 먼저 생각하는 것은 데이터베이스의 구조다. 그 다음에 도메인 로직을 생각하고 진행하는데 문제는 비즈니스 관점에서는 전혀 맞지 않는 방법이다. 

데이터베이스보다 도메인 로직을 먼저 진행하고 영속성 계층과 웹 계층을 진행해야한다.

왜 데이터베이스 중심적인 아키텍처가 될까?

가장 큰 원인은 ORM(object-relational mapping)를 계층형 아키텍처에 결합하기 때문이다.

이로 인해 비즈니스 규칙을 영속성 관점과 섞고 싶은 강한 유혹을 받게 된다.

도메인 계층에서 데이터베이스 엔티티 사용은 강한 결합을 유발

위의 이미지 같은 상황이 되면 강한 결합으로 인해 서비스에서 영속성 모델을 비즈니스 모델처럼 사용하게 되고, 이로 인해 영속성 계층에 관련된 작업(트랜잭션 등)을 해야만 한다.

결국엔 영속성 코드에 도메인 코드가 녹아들기 때문에 둘 중 하나만 바꾸는 것이 어려워진다.  

지름길을 택하기 쉬워진다

계층형 아키텍처의 유일한 규칙은 같은 계층의 컴포넌트나 아래의 계층만 접근이 가능하다. 그 외에는 팀마다 정한 규칙이 있을 수도 있고 개발도구로 강제할 수 있다.

 

만약 상위 컴포넌트로 접근이 필요한다면 트레이드오프로 해당 컴포넌트만 계층 아래로 내려버리면 단순하게 처리된다. 그렇지만 편해지자는 마음에, 바쁜 일정 속에서 지름길을 계속 허용하게 된다면 하위 계층은 점점 비대해질 수밖에 없다.

점점 비대해지는 영속성 계층

테스트하기 어려워진다

계층을 건너뛰는 경우를 본 적이 있을거다. 

웹 계층에서 영속성 계층을 의존

처음엔 트레이드 오프 생각으로 괜찮아 보인다. 하지만 계속된다면 2가지 문제가 발생하게 될 것이다.

첫번째 - 단 하나의 필드를 조작하는 것에 불과하더라도 도메인 로직을 웹 계층에 구현하게 되는 것.

두번째 - 웹 계층 테스트에서 도메인 계층뿐만 아니라 영속성 계층의 의존성을 끊기 위한 모킹(mocking)해야 한다는 것이다. 

결국엔 계층의 경계가 사라지는 진흙 덩어리가 되어버린다. 

유스케이스를 숨긴다

진흙 덩어리가 되어버린 계층형 아키텍처는 늪처럼 우리의 발목을 잡아버린다.

계층의 경계가 사라지고 여기저기 도메인 로직이 흩어졌기 때문이다. 

새로운 기능을 추가해도 적당한 위치를 찾기가 힘들고 기존의 코드를 유지보수하는 일이 어려워진다.

심지어 계층형 아키텍처에서는 도메인 '너비'를 강제하지 않기 때문에 비대해질 수 있다. 

비대해진 도메인

비대해진 서비스는 다양한 영속성 계층을 의존하게 되고, 많은 웹 계층의 컴포넌트가 이 서비스를 의존하는 진흙 덩어리가 되어버린다.  

동시 작업이 어려워진다

다가오는 일정의 압박속에 개발자를 마구잡이로 투입해서 빨리 완료하려는 프로젝트를 경험해본 적이 있다.

일반적인 맨먼스 미신으로 오히려 프로젝트 일정이 늦춰지는 결과만 발생했다.

지연되는 소프트웨어 프로젝트에 인력을 더하는 것은 개발을 늦출 뿐이다 - 맨먼스 미신, 프레데릭 P 브룩스

계층형 아키텍처에서는 추가적인 개발자가 투입된다고 일정에 도움이 되지 않는다.

개발자 3명이 각각 웹, 도메인, 영속성을 맡아 개발할 수 있을까? 전혀 그럴 수 없다.

데이터베이스 주도 설계는 영속성 로직이 도메인 로직과 뒤섞여서 각 측면으로 개발을 할 수 없다.

 

또한 넓은 서비스가 존재한다면 병합 충돌(merge conflict) 문제로 서로 다른 기능을 동시에 작업할 수 없다.  

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

올바른 구축과 추가적인 규칙을 적용하면 계층형 아키텍처는 유지보수가 쉽고 변화에 유연해진다.

하지만 계층형 아키텍처는 잘못된 방향으로 흘러가기 쉬운 구조다. 유리처럼 한번 균열이 생기기 시작하면 균열이 계속 사방으로 퍼지게 된다.

 

어떤 아키텍처에 상관없이 계층형 아키텍처의 함정을 염두에 두면 지름길에 빠지지 않고 유지보수하기 좋은 솔루션에 도움이 된다.

---

주관적인 생각을 더해 책의 내용을 정리하니 자세한 내용이 궁금하면 만들면서 배우는 클린 아키텍처를 참고해주세요.

클린 아키텍처 - 교보문고