SRP - 단일 책임 원칙
단일 책임 원칙은 거의 대다수가 “하나의 컴포넌트는 오로지 한 가지 일만 해야 한다”라고 알고 있다.
하지만, SOLID에 S 단일 책임 원칙의 실제 정의는 “컴포넌트를 변경하는 이유는 오직 하나뿐이어야 한다”이다.
SOLID를 공부하면서 나도 단일 책임 원칙은 하나의 일만 수행해야 한다라고만 알고 있었는데, 해당 책을 읽으면서 컴포넌트를 변경해야 하는 이유가 하나여야 한다는 정의가 좀 더 알맞는다고 생각이 들었다.
변경해야 하는 이유가 하나인 것은 즉, 하나의 일만 수행한다는 것을 의미한다.!
- 컴포넌트 A는 다른 모든 컴포넌트에 의존하고 있어서 다른 컴포넌트에 변경이 생길 때 같이 변경되어야 한다.
- 컴포넌트 A는 하나의 역할만 수행하는 게 아니라, 여러 역할을 수행하고 있다.
- 여러 컴포넌트와 연관되어 있어, 유지보수와 테스트가 어렵다.
SRP를 위반하는 경우
SRP를 위반하게 되면 프로젝트에 기능이 추가되거나 수정이 될 때 부수효과가 발생한다.
➡️ 코드의 한 영역을 변경했더니, 다른 곳에서 문제가 생긴다. 결합된 것이 많으면 생기는 문제
의존성 역전 원칙
단일 책임 원칙을 고수준에 적용할 때 상위 계층들이 하위 계층들에 비해 변경할 이유가 여지가 많다.
영속성 계층에 대한 도메인 계층의 의존성 때문에 영속성 계층을 변경할 때마다 도메인 계층에 변경이 필요할 수 있습니다.
DDD 설계에서 영속성 코드가 변경된다고 도메인 코드가 바뀌게 되면 안 된다.
이러한 의존성을 제거하기 위해 의존성 역전 원칙을 이용해 도메인 → 영속성 계층으로 흐르는 의존성을 역전시켜야 한다.
- 도메인 객체를 표현하고 있는 도메인 코드를 도메인 상태를 변경하고 관리하는 도메인 계층에 작성합니다.
- JPA를 통해 정의한 Entity Class와 별도로 도메인 그 자체를 나타내는 도메인 클래스를 도메인 계층에 작성합니다.
- 도메인 계층에 레포지토리에 대한 인터페이스를 만들고, 실제 레포지토리는 영속성 계층에서 구현합니다.
- 스프링 의존성 자동 주입을 이용해 DIP를 처리합니다.
클린 아키텍처란
설계가 비즈니스 규칙의 테스트를 용이하게 하고, 비즈니스 규칙은 프레임워크, 데이터베이스, UI 기술, 그 밖의 외부 애플리케이션이나 인터페이스로부터 독립적인 구조를 의미합니다.
➡️ 도메인 코드가 바깥으로 향하는 어떠한 의존성도 없어야 한다. 의존성 역전 원칙을 통해 모든 의존성이 도메인 계층으로 향하게 한다. 이로써, 도메인 중심적으로 설계할 수 있고, 도메인에 변화로만 변경이 발생하게 할 수 있습니다.
도메인 계층은 영속성 계층을 모르기 때문에 도메인 계층에서 사용한 엔티티 클래스를 영속성 계층과 함께 사용할 수 없다. 또한, 데이터베이스 테이블 정의한 부분과 도메인을 정의하는 부분을 분리해서 관리하는 것이 좋다.
➡️ 도메인 계층과 영속성 계층에서 데이터를 주고받을 때에는 도메인 클래스를 통해 주고받으며, Mapper 메서드를 구현하여 데이터를 변환한다.
헥사고날 아키텍처
육각형 안에는 도메인 엔티티와 이와 상호 작용하는 유스케이스가 존재합니다.
(외부로 향하는 의존성이 하나도 없으며, 모든 의존성이 코어(도메인)로 향합니다.)
바깥과 상호 작용은 어댑터를 이용하여 처리합니다.
- 웹 어댑터 : 웹 브라우저와 상호작용
- 외부 시스템 어댑터 : 외부 시스템과 상호 작용
- 영속성 어댑터 : 더이터베이스와 상호작용
왼쪽에 있는 어댑터들은 보통 애플리케이션을 호출하는 어댑터이므로 “주도하는 어댑터”라고 합니다.
오른쪽에 있는 어댑터들은 애플리케이션 코어에 의해 호출되기에 “주도되는 어댑터”라고 합니다.
애플리케이션 코어와 어댑터 간의 통신은 각각의 포트를 통해 처리됩니다.
➡️ 해당 아키텍처를 “ports and adapters” 라고 많이 부르는데, 모든 요청은 포트를 통해 흘러가며 어댑터를 통해 호출하거나 호출되기 때문에 포트를 애플리케이션 코어와 연결되는 통로, 어댑터를 외부와 연결되는 지점이라 할 수 있습니다.
결론
위에서 설명했듯이, 의존성 역전 원칙을 통해, 도메인 코드가 다른 바깥쪽 코드에 의존하지 않게 함으로써 영속성과 UI에 특화된 모든 문제로부터 도메인 로직과의 결합을 제거한다.
또한, 단일 책임 원칙을 통해 코드를 변경해야 할 이유를 줄이고 명확하게 하여 유지보수를 높일 수 있습니다.
클린 아키텍처란 무엇인가, 계층형 아키텍처의 문제점과 함정
일반적인 계층형 아키텍처계층형 아키텍처의 흐름은 간단하게 설명하면웹 계층에서 클라이언트 요청을 받습니다.요청을 받아 도메인 혹은 비즈니스 계층에 있는 서비스로 요청을 전달합니다.
kylo8.tistory.com
'개발 도서 > 만들면서 배우는 클린 아키텍처' 카테고리의 다른 글
| 클린 아키텍처 유지보수를 망치는 습관 3 가지 (1) | 2024.12.01 |
|---|---|
| 헥사고날 아키텍처에서 유스케이스 설계와 입출력 모델 관리 전략 (0) | 2024.11.30 |
| 헥사고날 아키텍처 구조 잡기, adapter-port 구조 (2) | 2024.11.19 |
| 클린 아키텍처란 무엇인가, 계층형 아키텍처의 문제점과 함정 (0) | 2024.11.13 |
