계층형 아키텍쳐
보통의 3 계층 아키텍쳐는 아래와 같다.
이렇게 되면 표현계층에서는 요청을 받아서 서비스 계층으로 넘긴뒤 도메인 로직을 수행하게 된다.
잘 작성한다면 도메인 로직에 영향을 주지않고, 표현 계층과 영속성 계층의 로직만 변경이 가능하다.
하지만 문제점이 생기는데 도메인 로직이 중점이 아닌 데이터베이스를 중점으로 설계하기 쉬워진다.
객체지향에서 기본적으로 협력에 의한 책임 주도 설계가 기본이 되는데
이때 기본적으로 객체가 가질 수 있는 state 에 의존하는 설계가 아니라
객체간의 협력에서 이룰 수 있는 행동을 기반으로 설계를 진행하는 것이 좋다.
이건 조영호님의 오브젝트 책을 보면 잘나와있는데 데이터를 중심으로 설계하게 되면
외부에서는 협력하는 객체에 대한 정보를 너무 많이 알게 된다.
대표적인 예시로 수많은 Getter 와 Setter 가 붙게된다면 사실 실패한 객체 설계라고 볼 수 있다.
이런 패턴의 경우 계층을 수직적으로 내리다 보니 애매한 계층이 생기게 된다.
하나의 문제가 Repository - Service - Entity 간의 순환 참조 고리가 생성된다.
그래서 의존성 역전 원칙을 통해서 이를 해결하는데 Spring 이 해결한 방식과 비슷하다.
Domain Layer
Spring 에서는 의존성 역전 방식을 이용해서 순환 참조 고리를 끊어 냈다.
일단 위의 그림과 같이 Domain Service 는 외부로 나가지 않는다.
그래서 외부세상과의 연결될 어댑터 가 필요하다.
Adapter Layer
클린 아키텍쳐에서 정의하는 어댑터는 아래와 같다.
위 이미지는 클린 아키텍쳐 이미지 입니다.
본문에 적혀있는 설명은 아래와 같다.
"The software in this layer is a set of adapters that convert data from the format most convenient for the use cases and entities, to the format most convenient for some external agency such as the Database or the Web."
쉽게 해석하면 외부 세계에서 사용하기 쉬운 형태 또는 유즈 케이스에서 이용하기 쉬운 형태로
데이터를 변환해주는 계층이라고 해석할 수 있다고 생각된다.
우리는 이러한 부분을 외부세계에 변화에 민감하지 않도록 안정적인 부분인 Interface 로 설계하는 것이 좋다.
보통 객체지향 세계에서는 Interface 가 Port 역할을 한다
보통 인바운드 어댑터는 위처럼 비즈니스 로직이 표출된 API 로 정의할 수도 있다.
보통의 웹 어플리케이션에서는 Controller 가 인바운드 어댑터가 될 수도 있다.
아웃바운드 어댑터는 반대로 비즈니스 로직이 외부 세상을 호출하는 방법이다.
위의 도식에서는 Repository Interface 가 아웃바운드 어댑터이다.
도메인 레이어에서 변경된 작업 내용에 대해 외부세계의 데이터베이스에 요청을 보낸다
그렇다면 예측되는 도식은 아래와 같이 될 것이다.
정리하며
오늘은 잘 정리한 것인가? 라는 의문이 든다.
여하튼 틀린 부분이 분명히 있을 수 있다.
이상한 부분이 있다면 댓글로 피드백을 주면 고마울것 같다. :)
참고한 글 / 자료
'Architecture' 카테고리의 다른 글
| 왜 계층간의 모델을 형성해야 하는가? (0) | 2022.03.07 |
|---|---|
| Web 계층에 Port 를 통해 더 자유로운 코드 짜기 (0) | 2022.01.20 |
| 협력과 메세지 (0) | 2021.12.02 |
| 응집도와 결합도 (1) | 2021.11.28 |
| 컴포넌트 (0) | 2021.11.17 |