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

(해당 내용은 '만들면서 배우는 클린 아키덱처'의 책을 공부하여 정리한 내용입니다)

계층형 아키텍처

계층형 아키텍처란~?

맨 위에 웹 계층에서는 요청을 받고 가운데 도메인 혹은 비즈니스 계층으로 요청을 보낸다

서비스에서 비즈니스 로직을 수행하고, 테이블에 조회, 변경, 저장을 위해 영속성 계층의 컴포넌트를 호출한다

우리는 지금도 이러한 계층형 아키텍처로 개발을 하고 있으며, 잘 만들어진 계층형 아키텍처는 아주 견고하고 선택의 폭을 넓히고, 요구사항과 외부 요인에 빠르게 적응할 수 있다

 

하지만 계층형 아키텍처는 코드에 나쁜 습관들이 스며들기 쉽고, 시간이 지날수록 수많은 허접들을 노출한다

 

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

우리가 만드는 대부분의 애플리케이션의 목적은 비즈니스를 관장하는 규칙이나 정책을 만들어서 사용자가 이러한 규칙과 정책을 더욱 편리하게 사용할 수 있게 한다

즉! 우리는 상태가 아니라 행동을 중심으로 개발을 해야 한다

 

하지만 그동안 만들어 본 애플리케이션의 유스케이스를 생각해보면, 데이터베이스의 구조를 먼저 생각하고 이를 토대로 비즈니스 로직을 구현했다

의존성에 방향에 따라 자연스럽게 구현한 것이라 전통적인 계층형 아키텍처의 합리적인 방법이다

하지만 비즈니스 관점에서는 전혀 맞지 않다

그리고 서비스에서 엔티티들과 리포지토리를 의존하게 되어 강한 결합이 생긴다

이로 인해 영속성과 관련된 계층들을 우선적으로 작업해야만 한다

 

지름길을 택하기 쉬워진다

전통적인 계층형 아키텍처에서 전체적으로 적용된 유일한 규칙은,

특정한 계층에서는 같은 계층에 있는 컴포넌트나 아래에 있는 계층에만 접근 가능하다는 것이다

 

개발 팀 내에서 합의한 다른 규칙이 있을 수도 있지만, 아키텍처 자체는 강제하는 규칙이 없어 지름길을 택하기 쉬워진다

예를 들어 컨트롤러에서 바로 엔티티를 호출해 작업을 할 수 있다

혹은 전부 하위계층으로 보내서 모든 영역에서 접근 가능하게 사용하게 할 수 있다

 

다른 누군가가 이미 했다면 나도 그렇게 개발할 확률이 늘어나고, 수년 후에는 개발과 유지보수가 더 어려워질 것이다

 

테스트하기 어려워진다

지름길을 택했던 코드들이 많아질수록 애플리케이션 전반에 걸쳐 책임이 섞이고 핵심 로직들이 퍼져나갈 확률이 높다

또한 웹 계층 테스트에서 도메인과 영속성 계층도 모킹해야 되므로 테스트의 복잡도가 올라간다

어느 순간 테스트 코드를 작성하는 것보다 종속성을 이해하고 목을 만드는데 더 많은 시간이 걸리게 된다

 

유스케이스를 숨긴다

새로운 코드를 짜는 시간보다 기존 코드를 변경하는데 더 많은 시간을 쓴다

기능을 추가하거나 변경할 적절한 위치를 찾는 일이 빈번하기 때문에 아키텍처는 코드를 빠르게 탐색하는데 도움이 돼야 한다 하지만 계층하키텍처가 그것을 도와주지는 않는다

좀 과장하면 서비스 한개는 많은 컨트롤러와 연관되어지고, 큰 서비스는 많은 엔티티들과 연관되어 있어 변경을 해야 할 때 영향도를 찾아내기가 쉽지 않다

 

동시 작업이 어려워진다

경영진은 인원이 더 투입될 경우 확실히 더 빨라진다고 생각한다

하지만 모든 상황에서 50명의 개발자가 있는 팀과 10명이 있는 개발자팀이 있다고 생각했을 때, 50명의 개발자가 팀이 5배 더 빠르게 일한다고 기대할 수 없다

대부분 서로 도움을 주고받으며 개발을 해야 하기 때문이다

 

특히 계층형 아키텍처에서는 영송석 계층이 먼저 만들어지고 그다음에 서비스를 개발해야 하기 때문에 동시에 여러 명의 개발자가 개발하는 게 쉽지 않다

 

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

올바르게 구축하고 몇 가지 추가적인 규칙들을 적용하면 계층형 아키텍처는 유지 보수하기 매우 쉽고 좋은 아키텍처이나 잘못된 방향으로 흘러가기 쉽고, 아주 엄격한 자기 훈련 없이는 시간이 지날수록 품질이 저하되고 유지보수가 하기 어려워진다

 

 

---

생각 정리

• 계층 용어 정리
  • 웹 계층 -> 컨트롤러
  • 도메인 계층 -> 서비스, 도메인
  • 영속성 계층 -> 엔티티, 리포지터리

개발을 처음 했을 때는 비즈니스 로직을 더 고민을 많이 했던 거 같은데....

시간이 흐를수록 Spring JPA를 사용하며 당연히 데이터베이스를 먼저 고민해서 생성하고, 엔티티를 생성하여 관계를 맺고 그 후에 비즈니스 로직을 개발했던 거 같다

그래서 책의 첫 부분을 읽으며 머리를 망치로 맏은 느낌이 들었다

너무 안전하게 개발하려 이미 운영 중인 다른 사람의 코드를 따라 하려고 하지 않았는가.. 하는 고민과 책의 내용처럼 지름길을 택하는 건 참 쉽고 다시 돌아오는 건 참 어렵다는 생각이 들었다

앞으로 코드를 작성할 때 지름길을 택하지 않도록 나 스스로 노력하고 다른 사람들과 코드 리뷰를 조금 더 많이 해야겠다