일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- 도메인 주도 개발 시작하기
- 아키텍처
- DDD
- Thymeleaf
- 클린아키텍처
- Java
- GrokkingFunctionalProgramming
- TDD
- 개발서적
- 유지보수
- 추상화 설계
- Spring
- web
- 헥사고날아키텍처
- 테스트
- 책스터디
- Kotlin
- 함수형프로그래밍
- FP
- 이펙티브코틀린
- Boot Legacy 차이점
- 조영호
- 스터디
- 만들면서배우는클린아키텍처
- 개발방법론
- 테스트주도개발
- 객체지향의사실과오해
- 코틀린
- 계층형아키텍처
- template
- Today
- Total
김동형수 개발기
만들면서 배우는 클린 아키텍처 - 01 정리 본문
01. 계층형 아키텍처의 문제는 무엇일까?
일반적인 웹어플리케이션의 계층형 아키텍처
웹 -> 도메인(비즈니스) -> 영속성
잘 만들어진 계층형 아키텍처는 변화하는 요구사항과 외부 요인에 빠르게 적응할 수 있게 해준다.
계층형 아키텍처는 데이터베이스 주도 설계를 유도한다.
계층형 아키텍처에서 의존도
웹 -> 도메인, 도메인 -> 영속성
삼단논법에 의거해서 웹 -> 영속성 의존이라는 결론 도출!
LIFIC 계층형 구조에서의 용어정리
웹 - 컨트롤러
도메인 - 서비스, 컴포넌트
영속성 - 리파지토리, 엔티티
영속성(데이터베이스)에 의존적인 계층형 아키텍처
실제로 개발하다보면 엔티티 의존적인 코드를 구현하고는 한다.
우리는 대체로 데이터베이스 모델링 -> 도메인 로직의 순서로 개발했을 것이다.
비지니스 관점에서는 위의 순서보다 도메인 로직 -> 데이터베이스 모델링의 순서로 만들어야 한다.
이런 까닭은 ORM 프레임워크 사용을 하기 때문이다.
계층형 아키텍처에서 도메인 -> 영속성 계층으로 단방향 접근할 수 있고 이에따라서 두 계층간 강한 결합이 생긴다. 그리고 영속성 계층 관련 여러 가지의 추가작업이 필요해진다.
도메인 계층과 영속성 계층간 결합도가 높기 떄문에 둘 중 하나만 변경하기 어려워진다. 이는 계층형 아키텍처의 반대되는 상황이다.
지름길을 택하기 쉬워진다
계층형 아키텍처에서 유일한 규칙은 같은 계층에 있는 컴포넌트 혹은 아래 계층에 접근이 가능하다는 규칙이다. 만약, 상위 계층에 위치한 컴포넌트에 접근해야한다면 해당 컴포넌트를 아래 계층으로 내리면 해결이 된다.
아래 계층으로 내리려는 컴포넌트가 이미 상위 계층에 다른 컴포넌트에 의존성이 있다면? 아래 -> 상위로 접근하는 상황이 발생할 것 같다.
위의 내용을 암묵적으로 용인하다보면 영속성 -> 도메인(하위->상위 계층으로) 접근하려는 코드는 늘어날 것 이고 헬퍼, 유틸 등을 늘려가면서 유지보수는 더욱 더 어려워질 것 같다.
위의 방법을 막기 위해선 테스트 코드를 통해서 하위 -> 상위 계층으로 접근하면 안되도록 처리가 필요하다.
이게 좋은 방법인가..? 규칙을 지키지 않는 내용을 걸러내기 위한 테스트 코드 삽입.
똥을 치우기 위한 새로운 누더기 도입과 같은 말로 보인다.
테스트하기 어려워진다
웹 -> 도메인 -> 영속성의 일반적인 구조를 가진 계층형 아키텍처에서 엔티티의 필드 단 하나만을 조작하려고 한다면 웹 -> 영속성의 순서로 접근하려는 생각을 가진 사람이 나타날 수 있다.
이에 따른 문제점
1. 웹 계층에서 도메인 로직을 작성하게된다. 도메인 계층의 책임이 웹 계층과 나눠지며 규칙에 어긋나게 된다.
2. 테스트할 때 도메인 계층뿐만 아니라, 영속성 계층도 모킹이 필요하다.
규모가 커짐에 따라 모킹하는데 더 많은 시간이 필요할 수 있다.
유스케이스를 숨긴다
위에 언급한 계층형 아키텍처 규칙 위반이 수 차례 발생해서 개발습관이 잡혀있다면, 기능을 추가하거나 변경할때 적절한 위치를 찾는데 어려워서 많은 시간이 소모될 것이다.
계층형 아키텍처에서는 도메인 서비스의 '너비'를 강제하는 규칙은 없다. 따라서 제품의 볼륨이 커짐에 따라서 '너비'가 넓은 서비스가 만들어질 수 있다. 이는 많은 웹 계층에서 하나의 서비스에 대한 의존성, 너비가 넓은 서비스에서 많은 영속성 계층에 의존성이 생길 수 있다.
'너비'가 넓어지면 한 서비스내에 많은 양의 메서드와 소스코드를 포함하는 케이스라고 생각이된다.
동시 작업이 어려워진다
여러 명의 개발자가 하나의 유스케이스에 매달려 작업한다고 가정해보면 계층형 아키텍처에서는 보편적으로 영속성 계층이 우선 개발되어야 하고 그에 따른 도메인 계층, 사용자 요청을 처리하는 웹 계층 순으로 개발이 되어야 하기 때문에 데이터베이스 주도 설계로 개발된 보편적인 프로젝트에서는 개발자 수와 개발속도가 비례하지 않는 듯 하다.
동일한 파일 작업을 하다보면 형상관리툴에서 충돌이 발생해서 해결하느라 개발시간보다 더 많은 시간을 투자해서 처리하는 경우도 종종 발생한다.
유지보수 가능한 소프트웨어를 만드는 데 어떻게 도움이 될까?
계층형 아키텍처에서도 제시하는 규칙과 추가적인 규칙을 잘 지키면서 개발하면 유지보수하기 쉬워진다고 한다. 그러나 보편적인 프로젝트에선 앞서 말한내용이 잘 지켜지지 않는 듯 하다.
초기개발에서 조차 앞서 나온 문제점들이 하나 둘 보이기 시작하고 있다..
반성이 필요해보인다.
어떤 아키텍처를 선택해서 개발하기 보단 정해진 규칙을 잘 따른다면 지속가능한 개발을 할 수 있는 프로젝트를 빌딩할 수 있을 것 같다.
'책 스터디 > [완료] 만들면서 배우는 클린아키텍처' 카테고리의 다른 글
만들면서 배우는 클린 아키텍처 - 06 정리 (0) | 2022.04.13 |
---|---|
만들면서 배우는 클린 아키텍처 - 05 정리 (0) | 2022.04.12 |
만들면서 배우는 클린 아키텍처 - 04 정리 (0) | 2022.04.11 |
만들면서 배우는 클린 아키텍처 - 03 정리 (0) | 2022.04.08 |
만들면서 배우는 클린 아키텍처 - 02 정리 (0) | 2022.04.07 |