계층형 아키텍쳐란?

일반적인 3계층 아키텍처

• 웹 계층, 도메인 계층, 영속성 계층으로 구성된 전통적인 웹 애플리케이션 구조
• 특정한 계층에서는 같은 계층에 있는 컴포넌트나 아래에 있는 계층에만 접근 가능
• 웹 계층에서 요청을 받아 도메인 혹은 비즈니스 계층에 있는 서비스로 요청을 보냄
• 서비스에서는 비즈니스 로직을 수행
• 도메인 엔티티의 현재 상태를 조회하거나 변경하기 위해 영속성 계층의 컴포넌트 호출

<aside> ⚠️ 잘 만들어진 계층형 아키텍처는 선택의 폭을 넓히고, 변화하는 요구사항과 외부 요인에 빠르게 적응할 수 있게 해준다. → 그러나 시간이 지날수록 소프트웨어를 점점 더 변경하기 어렵게 만드는 문제점이 존재!

</aside>

계층형 아키텍처 문제점?

• 데이터베이스 주도 설계를 유도!

  • 전통적인 계층형 아키텍처의 토대는 데이터베이스 ( 웹 → 도메인 → 영속성 의존)
  • 영속성 계층을 토대로 만들어지므로 데이터베이스에 의존적
  • 데이터베이스 중심적인 아키텍처가 만들어지는 가장 큰 원인은 ORM 프레임워크를 사용하기 때문
    • ORM에 의해 관리되는 엔티티들은 일반적으로 영속성 계층에 둔다.
    • 영속성 계층과 도메인 계층 사이에 강한 결합이 생긴다. → 서비스는 영속성 모델을 비즈니스 모델처럼 사용 → 영속성 계층 관련 작업들을 해야 함
  • 영속성 코드가 도메인 코드에 녹아들어가서 둘 중 하나만 바꾸는 것이 어려워짐! → 유연하고 선택의 폭을 넓혀준다던 계층형 아키텍처의 목표와 반대

• 테스트하기 어려움

  • 계층을 건너뛰는 형태가 생김
    • 예를 들어 엔티티의 필드를 단 하나만 조작하면 되는 경우 즉, 웹 계층에서 바로 영속성 계층에 접근한다면? ( 도메인 계층을 건너뛴다면? )
      • 도메인 로직을 웹 계층에 구현하게 됨 → 도메인 로직이 여기저기 흩어지게 됨!

  <aside> ⚠️ 따라서, 웹 계층 테스트를 할 때 도메인 계층 뿐만 아니라 영속성 계층도 모킹해야해서 단위 테스트 복잡도가 올라가게 됨

  </aside>

• 동시 작업 어려움

  • 모든 것이 영속성 계층 위에 만들어지기 때문에 영속성 계층 → 도메인 계층 → 웹 계층 순으로 개발이 진행 됨 → 따라서 특정 기능은 동시에 한 명의 개발자만 작업 가능하다!
  • 특히 넓은 서비스가 있다면 더욱이 동시 작업이 어려워짐 → 코드 병합 충돌 문제 야기

<aside> 📌 올바르게 구축하고 추가적인 규칙들을 적용하면 계층형 아키텍처도 유지보수하기 매우 쉬워지며 코드를 쉽게 변경하거나 추가할 수 있음

</aside>

의존성 역전 (계층형 아키텍처 단점 대안 방법)

1. 단일 책임 원칙

   • 컴포넌트를 변경하는 이유는 오직 하나뿐이어야 한다.
   • 하나의 컴포넌트에서 여러 기능을 포함하지 않도록 만들어서 의존성을 낮추는 것
   • 각 컴포넌트는 하나의 역할을 맡고 있기 때문에 다른 컴포넌트 변경에 대해 신경쓰지 않아도 됨

2. 의존성 역전 원칙

   • 계층간의 의존성은 웹 → 도메인 → 영속성 방향
   • 도메인의 영속성 의존 때문에 영속성 계층에 변화가 생길시 도메인 계층도 변경해야하는 경우가 많음
     • 의존성의 방향을 바꾸는 방법으로 이를 해결!

   

   도메인 계층에 인터페이스 도입 → 의존성 역전 ⇒ 영속성 계층이 도메인 계층에 의존

클린 아키텍처