전통적인 3계층 아키텍처
웹 → 도메인 → 영속성
아래 방향으로 접근 가능하다.
- 웹 계층: 요청을 받아 서비스로 요청을 보낸다.
- 도메인/비즈니스 계층:필요한 비즈니스 로직을 수행
- 영속성 계층: 도메인 엔티티의 현재 상태를 조회하거나 변경하기 위해 컴포넌트 호출
계층을 잘 이해하고 구성한다면 웹/영속성 계층에 독립적으로 도메인 로직을 작성 가능하다.
ex> 도메인 로직을 건드리지 않고 영속성 계층에 사용된 기술 변경 가능
단점
시간이 지날수록 소프트웨어를 점점 더 변경하기 어렵게 만드는 수많은 허점들을 노출한다.
1-1. 계층형 아키텍처는 데이터베이스 주도 설계를 유도한다
데이터베이스 관점
웹 → 도메인 → 영속성 흐름으로 의존하기 때문에 결국 데이터베이스에 의존하게 된다.
= 데이터베이스 기반으로 아키텍처를 설계한다
데이터베이스의 구조 → 토대로 도메인 로직 구현
- 의존성의 방향에 따른 자연스러운 현상이다
도메인 계층: 서비스
⬇
영속성 계층: 엔티티, 레포지토리- 아래 계층을 의존하기 때문에 서비스가 엔티티를 사용할 수 있게 된다. 그러면 두 계층간의 강한 결합이 생긴다.
→ 둘 중 하나만 바꾸는 것이 어려워진다. 유연하지 않다.
비즈니스 관점
- 도메인 로직을 제대로 이해했는지 확인하기 위해 로직을 먼저 만들어야 한다.
→ 이를 기반으로 웹, 영속성 계층 구현
1-2. 지름길을 택하기 쉬워진다
계층형 아키텍처의 유일한 규칙: 같은 계층이나 하위 계층에만 접근 가능하다.
만약에 상위 계층의 클래스가 필요하다면?
→ 하위 계층으로 내려버리면 된다.
→ 이 과정이 죄책감 없이 반복된다면 영속성(최하단) 계층의 크기는 매우 커질 것이다.
ex> 헬퍼, 유틸리티
1-3. 테스트하기 어려워진다
컨트롤러에서 엔티티를 바로 접근해도 된다면? (웹 → 영속성 계층)
- 도메인 로직을 웹 계층에서 구현하게 된다. 책임과 도메인 로직들이 여러 계층에 분산되게 된다.
- 유닛 테스트의 어려움. 웹 계층에서 도메인 계층뿐만 아니라 영속성 계층도 mocking 해야한다. 테스트의 복잡도
1-4. 유스케이스를 숨긴다
프로젝트를 변경하거나 추가할 경우, 그 위치를 찾기 위해 코드를 빠르게 탐색하는데 아키텍처가 도움이 되어야 한다.
다른 계층에서 접근하기 쉽게 하기 위해 몇몇 클래스들을 하위 계층으로 옮겼다면, 적절한 위치를 찾기 더 어려워진다.
많은 유스케이스를 담당하는 넓은 서비스가 만들어진다. → 영속성 계층에 많은 의존성을, 많은 웹 컴포넌트들은 또 이 서비스에 의존하게 된다.
유스케이스 하나씩만 담당하는 고도로 특화된 좁은 도메인 서비스를 만들자.
1-5. 동시 작업이 어려워진다
영속성 계층을 기반으로 모든 것이 만들어지기 때문에 개발자들이 여러 계층을 하나씩 맡아서 동시 작업을 진행할 수 없다.
1-6. 유지보수 가능한 소프트웨어를 만드는 데 어떻게 도움이 될까?
시간이 지날수록 품질이 저하되고 유지보수하기 어려워지기 쉽다.
느낀 점
서론
몇 개 하진 않았지만 프로젝트를 진행할 경우 나도 정확히 위의 일반적인 3계층 아키텍처로 컨트롤러, 서비스, 레포지토리 등을 설계하고 구현했다. 기존의 방식과 클린한 아키텍처를 어떤 점이 더 나은지 비교하고 공부해보고 싶어서 헥사고날 아키텍처에 참여하게 되었다.
데이터베이스 주도 설계
프로젝트를 구현 전 설계를 하는 단계에서 유즈케이스 분석보다는 필요한 기능, 요소들과 거기에서 필요한 도메인과 컬럼들을 빼내서 erd를 설계하고 그에 맞춰서 구현을 시작했다.
질문
- p4 서비스는 영속성 모델을 비즈니스 모델처럼 사용하게 되고 이로 인해 도메인 로직뿐만 아니라 즉시로딩/지연로딩, 데이터베이스 트랜잭션, 캐시 플러시 등등 영속성 계층과 관련된 작업들을 해야만 한다.
- 영속성 모델(엔티티) 와 비즈니스 모델(?)의 차이점은?
- 트랜잭션 구성은 원래 서비스에서 하는 것이 아닌가?
- p8 UserService 대신 RegisterUserService를 만들자. → 이렇게까지..? 내가 아직 개발 경험이 부족해서 그런 것일까?
