[만들면서 배우는 클린 아키텍처] 01. 계층형 아키텍처의 문제는 무엇일까?

계층 구조

 

 

Q. 계층형 아키텍처의 문제점은 무엇인가?

• 코드에 나쁜 습관이 스며들기 쉽다
• 시간이 지날수록 소프트웨어를 변경하기 어렵다

 

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

• 모든 것이 영속성 계층을 토대로 만들어진다
• 애플리케이션의 목적
  • 비즈니스를 관장하는 규칙, 정책을 반영한 모델을 생성해 편의성을 높이는 것
  • 상태(state)가 아니라 행동(behavior)을 중심으로 모델링한다
    • 행동이 상태를 바꾸는 주체

그런데 왜? 도메인 로직이 아닌 데이터베이스를 토대로 아키텍처를 만드는가

우리는 도메인 로직을 먼저 만들어야 한다

그래야 우리가 만드는 로직을 제대로 이해했는지 확인할 수 있다

그리고 이를 기반으로 영속성 계층과 웹 계층을 만들어야 한다

 

영속성 계층과 도메인 계층간의 강한 결합이 생긴다

 

 

ORM이 원인이다?

ORM에 의해 관리되는 엔티티들은 영속성 계층에 두고 도메인 계층에서는 이를 사용하기 마련 → 강한 결합이 발생

서비스에서 즉시로딩 / 지연로딩 / 데이터베이스 트랜잭션 / 캐시 플러시 등의 작업들을 하게됨

 

지름길을 택하기 쉬워진다

---

‘깨진 창문 이론’

상위 계층에 위치한 컴포넌트에 접근해야 할때 이를 내려버리는 우를 범한다

 

영속성 계층에서는 모든 것에 접근 가능하기 때문에 점점 비대해진다

 

• Util, Helper 등은 점차 내려가게 되어있다
• ‘지름길 모드’를 끄고 싶다면 계층구조를 탈피해야 한다

 

테스트하기 어려워진다

---

 

도메인 계층을 건너뛰는 것은 도메인 로직을 코드 여기저기에 흩어지게 만듬

 

웹 계층에서 바로 영속성 계층을 접근한다면?

• 도메인 로직을 웹 계층에 구현하게 되어 책임이 섞이고 도메인 로직이 파편화 된다
• 웹 계층 테스트시 영속성 계층도 모킹해야 한다

 

유스케이스를 숨긴다

---

• 도메인 로직이 여러 계층에 걸쳐 흩어지게 되면 새로운 기능을 추가할 적당한 위치를 찾기 어렵다
• 도메인 서비스의 폭이 아주 커질수도..

 

 

동시 작업이 어려워진다

---

계층형 아키텍처에서는 순서가 있다 → 특정 기능을 동시에 한 명의 개발자만 작업할 수 있다

코드에 넓은 서비스가 있다면 서로 다른 기능을 동시에 작업하는것도 어렵다.

같은 서비스를 건드려야 하기 때문이다

 

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

---

올바르게 구축하고 몇 가지 추가적인 규칙들을 적용하면 유지보수하기 쉽고 코드 변경도 용이하다

그러나 제대로 못하는 경우도 많지..

 

 

내 경험상 계층형 아키텍처도 상당히 유용한 부분이 많다

우선 단순하고, 정해진 원칙과 적절한 코드리뷰 들을 통해 의존성 관리, 서비스의 크기 등을 적절히 제한하면 오랜기간 잘 유지보수 되기도 한다

하지만 원칙과 적절하다는 것은 여지가 있다는 것을 의미하기도 한다. 깨진 창문이 발생한다면 앞에서 언급한 여러가지 문제가 발생할 수 있다.

다른 아키텍처들을 살펴보고 개발하려는 시스템의 규모와 특성에 맞게 적절한 아키텍처를 선택하도록 하자