반응형
- 톰 홈버그 저/박소은 역 | 위키북스 | 2021년 11월 26일
- 144 페이지로 편히 읽기 좋은 책
- 예전에 도서관에서 이 책을 빌렸는데 막상 읽으려니 눈에 안들어와서 미뤘다가 이번에 다시 빌려서 읽고 있다.
- 목차를 보면 각 장마다
유지보수 가능한 소프트웨어를 만드는 데 어떻게 도우밍 될까?라는 절이 있다. 어떤 부분이 더 개선이 되었는가를 설명해줘서 맥락을 따라가는데 도움이 될 것 같다.
1. 계층형 아키텍처의 문제는 무엇일까?
개발을 하면서 가장 익숙하고 많이 사용하는 아키텍처가 계층형 아키텍처(Layered Architecture)같다. 특히 스프링으로 개발할 땐 @Controller, @Service, @Repository를 사용하면 자연스럽게 계층형 아키텍처를 만들게 되는 느낌이다.
- 웹 계층의 요청을 받아 도메인(혹은 비즈니스) 계층에 있는 서비스로 요청
- 서비스 계층에서 비즈니스 로직 수행 후 도메인 엔티티 상태를 조회하거나 변경하기 위해서 영속성 계층의 컴포넌트 호출
- 견고한 아키텍처 패턴으로 웹계층이나 영속성 계층에 독립적으로 도메인 로직 작성가능 잘 만들면 선택의 폭을넓히고 변화하는 요구사항과 외부 요인에 빠르게 적응할 수 있게 해준다
패키지 구조나 아키텍처를 찾아보면 클린 아키텍처, 헥사고날 아키텍처 등의 개념을 찾아볼 수 있는데 기존의 계층형 아키텍처보다 무엇을 개선한걸까?
책의 저자는 계층형 아키텍처는 코드에 나쁜 습관들이 스며들기 쉽게 만들고, 시간이 지날수록 소프트웨어를 점점 더 변경하기 어렵게 만드는 수많은 허점들을 노출한다고 설명한다.
- 계층형 아키텍처는 데이터베이스 주도 설계를 유도한다
- 계층형 아키텍처에서는 웹 계층이 도메인 계층을, 도메인 계층이 영속성 계층을 바라보는 의존성 방향으로 인해 자연스럽게 데이터베이스 중심의 사고방식이 발생할 수 있다.
- 도메인 로직이 데이터베이스 스키마에 종속
- 영속성 코드와 도메인 코드 사이에 강한 결합이 생겨 독립적인 변경이 어려워지고, 즉시 로딩/지연 로딩, 트랜잭션 등 데이터베이스 관련 개념들이 비즈니스 로직에 침투
- 시간이 지날수록 비즈니스 요구사항 변화에 유연하게 대응하기 어려운 구조가 형성
- 지름길을 택하기 쉬워진다
- 웹 계층에서 영속성 계층으로 직접 접근하거나, 비즈니스 로직을 서비스가 아닌 컨트롤러나 리포지토리에 구현하는 경우가 발생
- 장기적으로는 코드의 품질과 유지보수성을 크게 저하시키는 기술 부채로 누적
- 테스트하기 어려워진다
- 도메인 로직이 영속성 계층과 강하게 결합되어 있어 단위 테스트 작성이 복잡해 진다.
- 유스케이스를 숨긴다
- 동시 작업이 어려워진다
- 넓은 서비스 클래스와 공유 도메인 모델로 인해 여러 개발자가 동시에 작업할 때 코드 충돌이 자주 발생
- 여러 유스케이스가 하나의 서비스 클래스에 구현되어 있다면, 서로 다른 기능을 개발하는 개발자들이 같은 파일을 수정하게 되어 병합 충돌 가능성이 높아진다.
올바르게 구축하기 위한 몇 가지 추가적인 규칙들을 적용하면 계층형 아키텍처는 유지보수하기 쉽고 쉽게 변경하거나 추가할 수 있다. 하지만 잘못된 방향으로 흘러갈 수 있는 여지를 남기는데 이런 함정을 염두해두면 유지보수하기 더 쉬운 솔루션을 만드는데 도움이 될 것이다.
반응형