사실이 아니라 공부한 내용과 생각을 정리한 글입니다. 언제든 가르침을 주신다면 감사하겠습니다.
(만들면서 배우는 클린 아키텍처를 읽으며 기록을 남기고 싶은 내용에 대해서 정리한 글입니다.)
클린 아키텍처의 가장 중요한 요소는, 핵심 도메인 로직을 외부로부터 보호하는 것이라는 관점으로 아래 글을 보면 도움이 될 것이라 생각합니다.
1. 계층형 아키텍처가 나쁜 이유
구체적인 이야기에 앞서 [웹 & 도메인 & 영속성] 중에 가장 중요한 계층이 무엇이라고 생각하는가?
- 웹은, 도메인 계층에서 수행한 비즈니스 로직의 결과를 사용자에게 보여주기 위한 계층이다.
- 도메인은, 실제 비즈니스와 연관된 로직을 담당하는 계층이다.
- 영속성은, 도메인 계층에서 수행한 비즈니스 로직의 결과를 영속화 하기 위한 계층이다.
저자는 실제 비즈니스와 연관된 로직을 담당하는 도메인 계층이 가장 핵심적이고 보호받아야 할 계층이라고 언급한다.
이러한 관점으로 전통적인 계층형 아키텍처를 바라보자.
각 계층간 의존 관계는 [웹 -> 도메인 -> 영속성 -> Database]로 흐른다.
이는 결국 전체 프로젝트가 Database 의존적일 수 밖에 없음을 의미한다. 즉, 핵심 도메인 로직은 구체적인 Database 기술에 따라 다르게 구현되어야 한다. 이는 도메인 계층이 영속성 계층으로부터 보호받지 못하고 있다는 것을 의미한다.
전통적인 계층형 아키텍처에서 전체적으로 적용되는 유일한 규칙은, 특정한 계층에서는 같은 계층에 있는 컴포넌트나 아래에 있는 계층만 접근 가능하다는 것이다.
이는 계층의 상단에 있을 수록 프로젝트 전반에서 사용될 수 없고, 계층의 하단에 있을수록 프로젝트 전반에서 사용될 수 있다는 것을 의미하기도 한다.
따라서, 전체 프로젝트에서 전반적으로 사용되는 공통 모듈의 경우 가장 하단의 계층에 마구잡이로 만들어질 가능성을 허용하는 구조이다.
또한, 계층과 계층 사이를 뛰어넘는 의존관계도 허용한다.
이로 인해 특정 한 계층이 비대해 지거나 각 계층 간의 명확한 경계를 망가뜨리는 결과를 초래할 가능성을 열어둔다.
2. 의존성 역전(DIP)
육각형 아키텍처를 보기에 앞서, 전통적인 계층형 아키텍처에서 Database로 향하던 단 방향 의존성을 도메인 계층 중심으로 바꾸는 방법에 대해 살펴본다.
도메인 계층에서 직접 영속성 계층의 엔티티와 리포지토리를 사용하는 것이 아니라, 별도의 도메인 계층 엔티티와 리포지토리 인터페이스를 만들고 영속성 계층의 리포지토리 구현체가 도메인 계층의 인터페이스를 의존하도록 변경하여 의존성을 역전시켰다.
이렇게 하면, 도메인 계층은 더는 영속성 계층에 의존하지 않는다. 즉, 영속성 계층으로부터 도메인 계층은 보호받을 수 있다.
3. 육각형 아키텍처
육각형 아키텍처는 모든 의존성을 핵심 도메인 계층에 집중시켜 도메인 계층을 보호하는 것이 핵심이다.
도메인 계층은 코어 역할을 하고 다른 모든 계층으로 부터 보호된다.
반대로, 다른 모든 계층은 도메인 계층을 중심으로 구성된다.
도메인 코드가 다른 바깥쪽 코드에 의존하지 않게 함으로써 영속성과 UI에 특화된 모든 문제로부터 도메인 로직의 결합을 제거하고 코드를 변경할 이유의 수를 줄일 수 있다.
또한, 도메인 코드는 비즈니스 문제에 딱 맞도록 자유롭게 모델링 될 수 있고, 영속성 코드와 UI 코드도 영속성 문제와 UI 문제에 맞게 자유롭게 모델링 될 수 있다.
4. 육각형 아키텍처와 Spring
5. 일반적인 유스케이스(도메인) 구현하기
'아키텍처' 카테고리의 다른 글
| 유지보수하기 좋은 소프트웨어 개발을 위한 아키텍처의 가치 (0) | 2024.06.29 |
|---|---|
| [도메인 주도 설계 핵심] 1장: 나에게 도메인 주도 설계는 (0) | 2023.01.14 |
댓글