[클린 아키텍처 01] What is problem of layered architecture?

 

스터디 해야지 ,,,

 

<< 클린 아키텍처 01 >>

'클린 아키텍처' 책 혼자서 가볍게 읽어봤지만 요번에 스터디로도 한번 더 읽게되서

겸사겸사 써보는 블로그 ^___^ 코드는 깃헙에 따로 올릴 계획이다  

 

계층형 아키텍처

지금 회사 프로젝트에서 쓰고있는 계층형 아키텍처(에서 살짝 변형되긴함)는 가장 보편적으로 많이 사용되는 아키텍처인 것 같다. 

개인적으로는 빠른 구현 및 코드 파악하기에는 가장 좋다고 생각함. 한 눈에 들어오잖아요? ㅎ;;

 

계층형 아키텍처 쏘 씸플

 

그러나 최근 계층형 아키텍처의 문제점들이 대두되면서 클린 아키텍처, 헥사고날 아키텍처를 선호하는 사람들이 많아졌는데,,

그렇다면 계층형 아키텍처의 문제점은 무엇이 있느냐

 

문제점

데이터베이스 중심의 설계

위에 그래프에도 보여지듯, 웹은 도메인에 의존하고, 도메인은 영속성에 의존한다 ==> 모든 것이 결국 데이터베이스에 의존하게 됨!

그러나 우리가 개발하는 애플리케이션은 뭐가 가장 중요한가? 바로 그것이 다루는 비즈니스가 중요하다! 

데이터베이스에 의존하게 되면 정작 중요한 도메인 중심으로 개발을 하지 못하게 되는 문제점이 발생한다. 

 

 

이렇게 도메인 계층에서 엔티티에 접근이 가능하다보니

마구마구 호출하게 되면 영속성 계층과 도메인 계층의 강한 결합이 생기게 될 수 밖에 읍따

 

문제점 1. 도메인 계층이나 영속성 계층에서의 변경이 어려워짐 (둘은 한몸이니깐;)

문제점 2. 영속성 계층과 관련된 작업들이 계속 늘어남 (즉시로딩, 트랜잭션, 캐시, ...)

 

깨진 유리창 이론

 

계층형 아키텍처의 유일한 규칙은 같은 계층에 있는 컴포넌트나, 아래에 있는 계층에만 접근 가능하다는 것인데..

그렇다보니 만약 상위 계층에 있는 컴포넌트에 접근하고 싶은 경우 계층 아래로 내려버림으로써 문제를 해결해버림 ㄷㄷ

모두가 아래로 아래로,, 영속성 컴포넌트가 아주 거대해지는 매직이 발생함

 

테스트가 어려움

만약 계층을 건너 뛰어서 컨트롤러에서 레포지토리에 접근하게 된다면 ...

웹 계층 테스트를 위해 웹, 도메인, 영속성 모두 Mocking 해야함 ㄷㄷㄷ 

 

유스케이스를 숨김

계층형 아키텍처는 도메인 서비스에 대한 규칙이 없기 때문에 모든 유스케이스를 담당하는 아주 넓은 서비스가 만들어질 수 이따.

이렇게 되면 서비스단 테스트가 어렵고, 작업해야 할 유즈케이스를 책임지는 서비스가 어딨는지 찾기도 어려움 

 

동시작업의 어려움

이건 진짜 공감되는 부분 중 하나인데, 개발자 여러명이서 특정 기능내 동시작업이 어려움!

계층형 아키텍처의 경우 영속성 계층 -> 도메인 계층 -> 웹 계층이 서로 의존되어 있어 쭈르르륵 만들어져야 한다 🥲

누구는 컨트롤러 만들고, 누구는 도메인, 누구는 DB Mapper 만들기도 짜치는 부분이라 결국 1 개발자 1 도메인 기능 개발 해야함

만약 같은 부분 건들면 머지할 때 충돌 고치기도 넘나 빡셈..

 

 

그러면 우리는 어떻게 해야할까?