아키텍처에서 중요한 것
- 프레임워크, db, cache는 세부사항 → 가장 중요하지는 않다
- db는 트랜잭션 지원, cache는 성능
- 가장 중요한 것은 핵심 비즈니스 로직과 유스케이스. ← DDD에서 도메인 및 모델 로직 이해도가 매우 중요하다 했는데 비슷한듯?
- 유스케이스(use case) = 입출력 + 비즈니스 로직
- 시스템이 있어야 유효
- 가장 중요한 도메인과 덜 중요한 인프라(세부사항)
- 도메인은 세부사항에 의존해서는 안됨!
- ex. 서비스에서 패키지 의존성 발생 (service에서 jdbc와 같은 특정 기술 의존, 패키지 의존성)
- db 접근기술 뿐만 아니라 비즈니스 로직도 변경됨.
- 계층형 아키텍처의 구성에 따라 몇 가지 이와 같은 문제점이 발생될 수 있음.
잘못된 계층형 아키텍처
- 비즈니스 계층이 영속성 계층 의존
- 현실에서 핵심은 비즈니스, db같은 세부사항이 아님.
- 넓은 서비스로 인해 유스케이스 파악 어려움.
- 넓은 서비스는 테스트 작성 및 관리도 어려워짐.
- 빈약한 엔티티 모델
- 객체에 정보만 갖고 있고, 아무런 기능도 갖고 있지 않는 모델
- 응집도가 떨어지고, 로직 재사용은 어려워짐.
- 의존관계 주입 및 스텁이 번잡해짐.
- 현업에서는 이렇게 클래스 설계하는 것이 굉장히 어려움 → 실수를 통해 깨닫는 것의 중요성
- SRP = 하나의 일만 해야된다? (X)
- 변경의 이유가 하나여야 한다 = 하나의 액터만 책임져야 한다
- 일반적인 계층형 아키텍처에서 이를 위반하기 쉬움
- 서로 다른 속도(수준)로 변경되는 코드들이 결합되기 쉽다.
클린 아키텍처란?
- 테스트하기 쉬운 아키텍처
- 외부 요인(프레임워크, 웹, db 등)이 없어도 유스케이스 전부를 단위테스트할 수 있어야 함
- 소리치는 아키텍처
- 새롭게 합류하는 프로그래머는 어떤 시스템인지, 어떤 유스케이스인지를 쉽게 파악할 수 있어야 함
- 어떤 프로그래밍 언어, 프레임워크, db를 사용하는지는 중요하지 않다
- 플러그인 아키텍처
- 변경을 수월하게
- 세부사항이 바뀌어도 코어 시스템인 핵심 비즈니스는 영향을 받지 않음
- 도메인 중심 아키텍처
- DIP
- 컴파일 의존성 ≠ 런타임 의존성
- 패키지 간의 의존성을 끊어내자