CH02 아키텍처 개요
네 개의 영역
앞에서 아키텍처에 대해서 간단히 살펴보았는데 여기서 자세히 한 번 더 짚고 넘어가고 있다.
표현영역
사용자(프론트에서의 사용자 요청 및 외부 백엔드 서버의 호출)의 요청에 대해서 응용영역이 이를 필요한 형식으로 받아 처리할 수 있도록 데이터를 변환해준다. 그리고 응용 영역에서 전달된 데이터를 사용자에게 전달하는 과정에서도 필요한 응답형식으로 바꿔서 전달하는 역할을 한다.
응용영역
사용자가 호출한 기능을 수행하는 영역이다. 하지만 도메인에 대한 로직이 구현되는 영역은 아니며, 도메인 영역의 객체들을 가져와 사용해서 필요한 기능을 수행한다. 기능을 직접 수행하는 것이 아니라 도메인 모델에 로직 수행을 위임하는 것이다.
도메인 영역
엔티티, 값 객체로 이뤄진 도메인 객체들을 말한다. 각 해당 도메인의 핵심 로직이 구현된 레이어다. 여기서 구현된 로직들이 응용 영역에서 호출되어 사용된다.
인프라스트럭처 영역
구현 기술에 관한 영역이다. 어플리케이션 내 어떤 영역에서든지 특정 기술을 쓸 때 인프라스트럭처 레이어를 통해서 사용하게 된다. 당연한 이야기이지만 비즈니스 로직은 일체 들어가지 않으며 오로지 기술의 구현을 책임지고 이를 라이브러리처럼 다른 레이어에 제공하는 것이 핵심인 레이어이다.
계층 구조 아키텍처
상위계층에서 바로 밑 하위 계층으로의 의존만 하는 것이 일반적인 구조이지만 편의를 위해 아래와 같이 더 아래 계층으로의 의존도 발생한다.
그런데 이 때 문제가 되는 것이 응용 계층에서 인프라스트럭처 계층을 의존하는 과정에서 '특정한 기술에 종속'되는 현상이 발생한다는 것이다. 이렇게 되면 두 가지 문제가 발생한다.
기술을 변경해야할 상황이 생겼을때 이미 응용 계층에서 많은 코드가 특정 기술에 종속되어 있어서 기술 변경이 어려워진다.
해당 응용 서비스 코드를 테스트하려면 의존하고 있는 그 특정 기술까지 함께 동작해야해서 의도치 않게 검증 단위가 커진다.
극단적인 예시로 만약 JPA 에 종속되어 있다는 가정을 해본다면, 응용 계층에서 JPA 의 dirty checking 이나 write behind 와 같은 특정한 기술을 감안하고 코드를 작성해 놨는데 이를 document DB 등으로 바꾸게 되면 전반적인 로직 자체를 다시 작성해야 하는 상황이 발생한다.
DIP(Dependency Inversion Principle)
DIP 를 이해하기 위해서는 먼저 고수준 모듈과 저수준 모듈이라는 두 개념에 대해서 이해가 필요하다.
고수준 모듈과 저수준 모듈
책에서 예로 들고 있는 고수준 모듈과 저수준 모듈이다. 고수준 모듈은 의미 있는 단일 기능을 제공하는 모듈이며, 저수준 모듈은 고수준 모듈의 기능을 구현하기 위한 구체화된 하위 기능을 의미한다. 위키백과에는 고수준 모듈은 '정책 결정' 이고 하위 모듈은 '세부 사항' 이라고 정리되어 있다.
DIP 구현
고수준 모듈이 저수준 모듈에 의존하는 것에서 문제가 생긴 것이기 때문에 이를 역전 시키면 된다. 즉, 고수준 모듈에서 저수준 모듈을 의존하던 의존의 방향성을 저수준 모듈이 고수준 모듈을 의존하도록 역전 시키는 것이다.
아래는 위키 백과에 있는 그림이다. 위에 있는 것이 전통적인 형태의 의존 관계로 고수준이 저수준에 의존하고 있는 모습이고 아래의 모습이 추상화(인터페이스)를 이용해서 저수준(Mechanism Layer)이 고수준에 의존하도록 의존 방향을 역전 시킨 모습이다.
이렇게 고수준 모듈에 인터페이스를 만들고 저수준 모듈이 이 인터페이스를 구현하고 이를 사용해야하는 고수준 모듈에서는 동일한 계층의 해당 인터페이스를 의존하면 DIP 가 적용되는 것이다. 이렇게 하면 위에서 말한 고수준 모듈이 저수준 모듈에 직접 의존함으로써 생기는 문제 두 가지가 해결된다.
기술을 변경해야할 상황이 생겼을때 이미 응용 계층에서 많은 코드가 특정 기술에 종속되어 있어서 기술 변경이 어려워진다. 해결: 응용 계층에서는 오직 인터페이스와 인터페이스가 제공해주는 메소드에만 의존하는 형태로 바뀔 것이고, 기술 변경이 발생할 경우 구현체만 바꿔주면 된다. 즉, 기술 변경이 발생해도 응용 계층에는 코드 변경이 발생하지 않아도 되는 것이다.
해당 응용 서비스 코드를 테스트하려면 의존하고 있는 그 특정 기술까지 함께 동작해야해서 의도치 않게 검증 단위가 커진다. 해결: 인터페이스에 의존함으로써 테스트 때는 다른 구현체를 손쉽게 사용할 수 있다. 예를 들어 프로덕션 환경에서는 JPA 를 사용하고 테스트에서는 InMemory 에서 동작하도록 Repository 를 직접 만들 수도 있는 것이다.
DIP 주의사항
핵심은 추상화를 통해서 저수준이 고수준에 의존하도록 하는 것이다. 따라서 인터페이스 혹은 추상 클래스는 고수준 모듈에 속해야 한다.
위와 같은 형태가 제대로 구현된 DIP 이다.
위와 같은 형태가 책에서 소개하는 잘못된 DIP 의 구현 사례이다. 얼핏 보면 고수준 모듈이 저수준 모듈에 직접 의존하지 않고 추상계층에 의존하고 있는 모습이지만 인터페이스 자체도 저수준 모듈이므로 결국 고수준이 저수준에 의존하고 있는 모양 그대로이다.
결국 추상화된 계층이 어느 모듈에 속해야 하는지 정확히 이해하는 것과 이에 맞는 패키지에 위치 시키면 된다.
결론적으로 DIP를 적용시키면 인프라스트럭처 계층이 응용 계층 및 도메인 계층에 의존하게 된다. 아래 그림은 책에서 소개하고 있는 최종적으로 DIP 가 잘 적용된 아키텍처이다.
이렇게 DIP를 녹여서 구조를 설계함으로써 기술만 바꿔야할 경우 응용 계층이나 도메인 계층에 변경이 발생하지 않고 저수준 모듈의 구현체에만 변경이 발생하게 된다.
도메인 영역의 주요 구성요소
도메인 영역의 주요 구성 요소는 아래와 같다.
ENTITY
고유의 식별자를 갖는 객체로 자신의 라이프 사이클을 가진다. 도메인 로직을 구현하는 핵심 단위이다.
VALUE
ENTITY 에 속하는 객체로 식별자가 없다. ENTITY 처럼 데이터와 기능을 제공한다. VALUE 는 무조건 불변 객체로 구현한다.
AGGREGATE
연관된 ENTITY 와 VALUE 들을 묶은 단위이다. Order 를 예로 들면 OrderLine, Orderer 등을 한데 묶어 AGGREGATE 라고 할 수 있다. 하나의 AGGREGATE 가 가지는 ENTITY의 수는 높은 확률로 1개이다. 간혹 두 개 이상의 ENTITY 로 구성된 AGGREGATE가 있을 수는 있지만 드물다. 둘 이상의 AGGREGATE에 속하는 ENTITY는 존재하지 않으며 하나의 AGGREGATE는 루트 ENTITY를 갖고 있다.
REPOSITORY
도메인 모델의 영속성을 처리한다. DIP 에서 정리했듯이 추상화된 형태이며 이것의 구현체는 인프라스트럭처 영역에 있다.
DOMAIN SERVICE
특정한 AGGREGATE 하나가 제공해줄 수 없는 도메인 로직의 경우에 DOMAIN SERVICE 가 응용 계층에서 도메인 계층의 로직을 조합해서 기능을 제공하듯이 여러 도메인 로직을 조합해서 기능을 제공해준다.
AGGREGATE (애그리거트) 추가 설명
아래는 DDD 세레나데의 강의 자료에서 배웠던 내용인데 현재 책의 내용과 일치하여 옮긴다.
AGGREGATE
관련 객체를 하나로 묶은 군집
애그리거트는 군집에 속한 객체들을 관리하는 루트 엔티티를 갖는다.
애그리거트로 묶어서 바라보면 좀 더 상위 수준에서 도메인 모델 간의 관계를 파악할 수 있다.
애그리거트에 속한 객체는 유사하거나 동일한 라이프사이클을 갖는다.
한 애그리거트에 속한 객체는 다른 애그리거트에 속하지 않는다.
두 개 이상의 엔티티로 구성되는 애그리거트는 드물게 존재한다.(거의 하나의 ENTITY 라는 뜻이다)
AGGREGATE ROOT (ROOT ENTITY)
애그리거트 루트의 핵심 역할은 애그리거트의 일관성이 깨지지 않도록 하는 것이다.
애그리거트 루트는 애그리거트가 제공해야 할 도메인 기능을 구현한다.
이는 애그리거트의 내부 구현을 숨겨서 애그리거트 단위로 구현을 캡슐화할 수 있도록 돕는다.
루트 엔티티는 애그리거트에 속해 있는 엔티티와 밸류 객체를 이용해서 애그리거트가 구현해야 할 기능을 제공한다.
그래서 애그리거트에 속한 특정 ENTITY나 VALUE 에 접근해야 할 경우 반드시 ROOT ENTITY 를 통해서 접근하고 처리를 하는 것이 바람직하다.
만약 ROOT ENTITY 를 통하지 않고 직접 접근해서 처리를 해야할 일이 많고, 그게 일반적일 경우 애초에 해당 ENTITY 가 해당 애그리거트가 아닐 수 있다.
Repository 추가 설명
DIP 부터 계속 언급되고 있지만 도메인 계층에 Repository 가 있는 이유는 인프라스트럭처 계층에서 이를 실제 구현하도록 해서 고수준이 저수준을 직접 의존하는 것을 막기 위함이다.
가장 중요한 것은 Repository 는 테이블 단위가 아니라 애그리거트 단위로 존재해야 한다는 것이다. 책보다는 DDD 세레나데에서 배운 내용이 더 구체적인 것 같아서 아래에 남긴다.
Repository
엔티티나 밸류가 요구사항에서 도출되는 도메인 모델이라면 리포지터리는 구현을 위한 도메인 모델
애그리거트 단위로 도메인 객체를 저장하고 조회하는 기능을 정의한다.
애그리거트를 구하는 리포지터리 메서드는 완전한 애그리거트를 제공해야 한다.
리포지터리가 완전한 애그리거트를 제공하지 않으면, 필드나 값이 올바르지 않아 애그리거트의 기능을 실행하는 - 도중에 NullPointerException과 같은 문제가 발생하게 된다.
리포지토리는 애그리거트(루트) 단위로 존재하며 테이블 단위로 존재하는 것이 아니다.
Last updated
