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

전통적인 계층형 아키텍처

1. 웹 계층에서 요청을 받음

2. 도메인 혹은 비즈니스 계층에 있는 서비스로 요청을 보냄

3. 도메인 엔티티의 현재 상태를 조회하거나 변경하기 위해 영속성 계층의 컴포넌트 호출

 

계층형 아키텍처의 문제점

웹 -> 도메인 -> 영속성으로 이어지기 때문에 자연스럽게 데이터베이스에 의존하게 됩니다.

이렇게 되면 '도메인 로직'이 아니라 '데이터베이스'를 토대로 아키텍처가 만들어집니다.

 

전통적인 계층형 아키텍처에서는 합리적인 방법입니다.

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

 

이렇게 된 가장 큰 원인은 ORM 프레임워크를 사용하기 때문입니다.

ORM에 의해 관리되는 엔티티들은 일반적으로 영속성 계층에 두게 되고 도메인 계층 사이에 강한 결합이 생기게 됩니다.

 

서비스는 영속성 모델을 비즈니스 모델처럼 사용하게 되고 즉시로직, 지연 로딩, 데이터베이스 트랜잭션, 캐시 플러시 등등 영속성 계층과 관련된 작업들을 해야만 합니다.

 

이제 영속성 코드가 도메인 코드에 녹아들어가게 되었으며 둘 중 하나만 바꾸는 것이 어려워집니다.

유연하고 선택의 폭을 넓혀 주어야 하는 계층형 아키텍처의 목표와 정확히 반대되는 상황입니다.

 

지름길을 택하기 쉬워진다

전통적인 계층형 아키텍처에서 전체적으로 적용되는 유일한 규칙은, 같은 계층에 있는 컴포넌트나 아래에 있는 계층에만 접근 가능하다는 것입니다.

 

하지만 상위 계층에 위치한 컴포넌트에 접근하기 위해 간단하게 컴포넌트를 계층 아래로 내려버릴 수 있습니다.

만약 마감 상황이 다가오고, 과거에도 이와 똑같은 전력이 있다면 심리적 부담감은 훨씬 낮아지기 마련입니다.

 

물론 개발 팀 내에서 합의한 다른 규칙들이 있을 수 있고, 그중 일부는 개발 도구를 이용해 강제화 할 수 있습니다.

 

테스트하기 어려워진다

웹 계층이 꼭 도메인 계층을 거쳐서 영속성 계층으로 향해야 할까?

 

개인적으로도 종종 많이 했던 생각입니다.

 

하지만 유스케이스가 확장됨에 따라 더 많은 로직이 웹 계층에 추가될 수 있습니다.

또한 웹 계층 테스트에서 도메인 계층뿐만 아니라 영속성 계층도 mocking 해야 하는 테스트 복잡도가 발생하게 됩니다.

 

어느 순간이 지나면 실제로 테스트 코드를 작성하는 것보다 종속성을 이해하고 mock을 만드는 데 더 많은 시간이 걸리게 됩니다.

 

유스케이스를 숨긴다

앞의 사례에서 보았듯 도메인 로직이 여러 계층에 걸쳐 흩어지기 쉽습니다.

유스케이스가 '간단'해서 도메인 계층을 생략한다면 웹 계층에 존재할 수도 있습니다.

아니면 도메인 계층과 영속성 계층 모두에서 접근할 수 있도록 특정 컴포넌트를 아래로 내렸다면 영속성 계층에 존재할 수도 있습니다.

이런 경우에는 새로운 기능을 추가할 적당한 위치를 찾는 일은 이미 어려워진 상태입니다.

 

동시 작업이 어려워진다

일반적으로 경영진들은 특정 날짜에 완성되기를 바랍니다.

특정 날짜까지 소프트웨어가 완성되어야 한다는 것은 여러 작업을 동시해 해야 한다는 것을 의미합니다.

 

"지연되는 소프트웨어 프로젝트에 인력을 더하는 것은 개발을 늦출 뿐이다."

 

10명이 되는 개발팀을 50명으로 늘리면 개발 속도가 5배 빨라질 것이라고 기대할 수는 없습니다.

대부분 각자 분리된 파트를 개발하며 서로 도움을 주고받으며 개발해야 합니다.

 

서로 다른 유스케이스에 대한 작업을 하게 되면 같은 서비스를 동시에 편집하기 때문에 merge conflict가 발생하게 됩니다.

 

반대로 3명의 개발자가 각각 웹, 도메인, 영속성 계층에서 기능을 추가하게 되더라도 문제는 발생합니다.

영속성 계층이 먼저 개발되어야 하고, 그다음에 도메인 계층, 그다음에 웹 계층을 만들어야 합니다.

그렇기 때문에 특정 기능은 동시에 한 명의 개발자만 작업할 수 있습니다.

 

개발자들이 인터페이스를 먼저 같이 정의하고 이를 토대로 작업해도 됩니다.

하지만 데이터베이스 주도 설계는 영속성 로직이 도메인 로직과 너무 뒤섞여서 각 측면을 개별적으로 작업하기 어렵습니다.

 

 

개인적인 생각

동시작업의 경우에는 merge 시 conflict만 잘 해결하면 동시 작업이 그렇게 어려울 것이라고 생각이 들지는 않습니다.

기존에 전통적인 계층형 아키텍처를 많이 사용했기 때문에 공감이 많이 되는 챕터였습니다.

 

 

삼색펜 스터디

• 빨강 : 핵심
• 파랑 : 나름 중요한 내용
• 초록: 재밌다는 생각이 드는 내용

 

잘 만든 계층형 아키텍처는 도메인 로직에 영향을 주지 않고 웹 계층과 영속성 계층에 사용된 기술을 변경할 수 있다.

하지만 나쁜 습관들이 스며들기 쉽고 시간이 지날수록 점점 더 변경하기 어려워진다.

계층형 아키텍처의 토대는 데이터베이스다.

행동이 상태를 바꾸는 주체이기 때문에 행동이 비즈니스를 이끌어가며 이는 비즈니스 관점에선 전혀 맞지 않는 방법이다.

 

UserService에서 사용자 등록 유스케이스를 찾는 대신 RegisterUserService를 바로 열어서 작업을 시작한다. (유스케이스를 숨기지마라)

새로운 코드를 짜는 데 시간을 쓰기보다는 기존 코드를 바꾸는 데 더 많은 시간을 쓴다.

지름길을 대수롭게 여기지 말자

지연되는 소프트웨어 프로젝트에 인력을 더하는 것은 개발을 늦출 뿐이다

 

동시 작업이 어려워진다. (conflict 되지않고 바로 develop을 기준으로 rebase될때 좋다..)

프로젝트 매니저가 개발팀에 새로운 마감일을 설정할 때마다 조금씩 느슨해지기 마련이다. (마감일이 촉박하다면 코드퀄리티는 급격히 낮아지게 된다..)