CH04 도메인 주도 설계 아키텍처

1. 계층형 아키텍처

강의에서는 위와 같은 구조를 4티어 라고 표현했는데, 소프트웨어 전체를 위와 같은 layer 로 나누고 의존은 아래 방향으로 단방향 의존이 되는 것이 이상적이라는 것을 나타내는 그림이다.(뒤에 설명을 더 하겠지만 사실은 이게 이상적인 형태가 아니다)

한 발 더 나아가서, 결국 위와 같이 layer를 나눠서 인식하는 이유는 객체를 나누는 대원칙처럼 layer 단위로 책임과 역할을 구분하는 것이 유연하면서도 응집력있는 설계에 가깝다는 판단이 있기 때문이다.

DDD를 학습하고 나면 ‘비즈니스 로직 수행은 어느 곳에 하는 것이 좋을까?’ 라는 질문에 대한 대답은 결국 ‘도메인 레이어' 가 된다.

왜?

도메인 레이어(entity, value object -> aggregate -> domain service)에서 비즈니스 로직 수행을 처리하는 것이 곧 Context를 분리해서 비즈니스 규칙 및 정책을 준수시킨다는 것이고, 이러한 행위는 곧 다른 Context를 고려할 필요 없이 오직 해당 Context에만 집중할 수 있다는 뜻이기 때문에 더 정확하고 안정적인 프로그램이 될 수 있기 때문이다.

다르게 이야기하자면 고립을 시킴으로써 조금 더 자유롭게 고립된 범위 내에서 다른 것들을 신경쓰지 않고 해당 Context에만 집중할 수 있다는 뜻이다.

그런 의미에서 이번 수업의 ‘계층형 아키텍처'는 단지 ‘4티어는 이런거고 의존은 단방향으로 이뤄져야한다’는 단순한 이야기를 하고자 하는 것이 아니고 그 아래에 담긴 대전제를 다시 한번 짚어보고 넘어가야 한다는 메세지를 전달하고 있는 개념이라는 생각이 들었다.

application layer와 domain layer의 경계를 이해하는 데에는 수업 자료에 나온 내용이 도움이 많이 되어서 아래에 첨부한다.

* 사용자의 요청을 처리하기 위해 리포지터리로부터 도메인 객체를 구하고, 도메인 객체를 사용한다.
* 로직을 직접 수행하기보다는 도메인 모델에 로직 수행을 위임한다.
* 도메인 객체 간의 실행 흐름을 제어
* 트랜잭션 처리
* 도메인 영역에서 발생시킨 이벤트를 처리

코드로 보면 아래와 같이 추상화 할 수 있다.

public Result doSomeFunc(SomeReq req) {
    // 1. 리포지터리에서 애그리거트를 구한다.
    SomeAgg agg = someAggRepository.findById(req.getId());
    checkNull(agg);
    // 2. 애그리거트의 도메인 기능을 실행한다.
    agg.doFunc(req.getValue());
    // 3. 결과를 리턴한다.
    return createSuccessResult(agg);
}

그런데 이 4티어의 의존 방향이 후에 나올 DIP를 적용하면 바뀌게 된다. 기본적으로 외부의 영향을 받지 않는 헥사곤 아키텍처가 가장 이상적인 구조라고 하는데 뒤에 이어서 설명하겠다.

2. DTO(Data Transfer Object) 의 효용가치 다시 생각해보기

DTO에 대해서 강사님이 재미있는 관점을 소개해주셨는데 참 인상적이었다. DTO에 과연 O를 붙여줘도 되는지 모르겠다는 것이었다. 객체가 되려면 책임과 역할이 있어야하는데 단지 데이터를 실어나르는 구조체에 Object라는 네이밍 자체가 ‘자격미달’의 느낌이라는 이야기셨는데 생각해보지도 못했던 관점이라서 좀 새로웠다.

위 layer 에 대한 수업에 이어서 DTO가 나온 이유는 결국 layer간에 데이터를 전달할 때, 혹은 layer 를 넘어서 서버에서 클라이언트로 데이터를 넘겨줄 때 DTO를 많이 사용하게 되는데 이때 DTO가 많아질수록 발생되는 복잡도를 어떻게 핸들링할지가 필연적으로 발생하는 이슈이기 때문이다.

핵심 이슈는 ‘DTO를 필요할 때마다 만들어서 사용을 하는게 과연 최선일까?’ 였다. 그런 맥락에서 ‘ Domain Model Everywhere’라는 원칙하에 도메인 모델을 직접 사용하는 방법도 있었는데 장점과 단점이 분명했다.

Domain Model Everywhere

도메인 모델을 데이터 전달의 목적으로 사용하게 될 경우의 단점으로 사용하는 라이브러리에 따라서 불필요하게 getter, setter가 필요한 경우가 있었다.

자바빈 스펙을 따르는 라이브러리의 경우 getter, setter가 있어야 가능하다던가 하는 문제가 있기 때문이다. 예를 들어 직렬화, 역직렬화를 하는 경우에 어떤 라이브러리를 사용하냐에 따라서 getter, setter가 필요할 수 있다.

뿐만 아니라 클라이언트의 요구에 유연하게 대응하지 못한다는 단점이 있다. 요구에 따라 이것저것 붙이게 되면 필요한 스펙만 구현한 절제된 도메인 모델이 오염될 수 있기 때문에 변화에는 신중해야하는데 이에 반해 클라이언트의 요구가 다변적일 가능성이 크기 때문이다.

나는 개인적으로 클라이언트 개발자를 위해서 데이터를 서버단에서 가공해줘야할 일이 많았는데(서버 개발자라면 누구나 그렇지 않을까 싶기도 하다), 그렇게 가공된 데이터가 담길 모델이 서버 내부에서 layer간 소통에 사용될 모델에는 적합도가 크게 떨어졌다.

왜냐면 사용자를 위해서 가공될 필요 없이 raw 데이터 그대로 소통해도 되는데 굳이 가공처리가 된 데이터를 품기 위해서 타입이 쓸데없이 배열이 된다던가 필드명이 변경되어야 한다던가 하는 상황이 많았기 때문이다.

그래서 나는 필요한 경우의 DTO를 만들어서 변환 작업을 한번 거치는게 좋은 것 같다. 극단적으로 도메인 모델에서 어떤 값도 바뀔 필요가 없어서 그대로 필드들을 옮겨서 set만 해줘도 된다고 하더라도 말이다.

3. 의존 역전 원칙(DIP) 이해하기

이건 DDD 관련 내용이라기 보다는 일반적인 의존 역전의 장점에 관한 내용이었다. 하지만 의존 역전 원칙을 준수하는 개발이 곧 유연한 DDD 설계와도 연관성이 깊기 때문에 커리큘럼상 나온 것 같다는 생각이 든다.

강의에서는 의존 역전 원칙을 설명하기 위한 사전 개념으로 고수준 모듈과 저수준 모듈이라는 개념을 설명하고 있다. 고수준 모듈은 ‘어떤 의미 있는 단일 기능을 제공하는 모듈’로 강의에서는 ‘가격 할인 계산’을 예시로 들고 있다.

저수준 모듈은 고수준 모듈을 위한 하위 로직을 수행하는 모듈로 예시에서 ‘가격 할인 계산’을 위한 사용자의 등급별 할인율 적용, 사용자 보유 쿠폰 적용 등을 예시로 들수 있다.

통상적인 경우에서 의존 역전 원칙이 적용되지 않는다면 고수준 모듈은 저수준 모듈에 의존하고 있다. 그래서 저수준 모듈이 변경되면 이를 의존하고 있는 고수준 모듈도 영향을 많이 받게 된다.

이런 상황에서 저수준 모듈이 고수준 모듈을 의존하도록 하는 것이 바로 DIP(Dependency Inversion Principle, 의존 역전 원칙)를 적용하는 목적이다. 고수준 모듈이 의존하는 대상이 저수준 모듈에서 구현을 추상화한 인터페이스에 의존하는 것이다.

이렇게 함으로써 저수준 모듈이 변경되더라도 인터페이스의 구현만 바뀔 뿐, 고수준 모듈에 영향을 주는 요소는 없기 때문에 고수준 모듈의 독립성이 더 확보된다.

내가 진행한 미션을 예로 들면 Name을 만들때 외부 API를 호출해서 비속어가 포함되지 않도록 하는 로직을 만들었는데, 이 외부 API를 송수신하는 객체를 Name이 직접 참조하지 않고 인터페이스를 참조하도록 만들어서 외부 API 가 변경되더라도 Name에는 전혀 지장이 없도록 만든 것이 DIP가 적용된 부분이라 할 수 있다.

@FunctionalInterface
public interface Profanities {
    boolean contains(String name);
}

위와 같이 하나의 메소드만 있다고 해도 인터페이스를 구현해준뒤 사용할 때에는 이 구현체를 넣어준다.

@Embeddable
public class Name {
    private String value;

    protected Name() {
    }

    public Name(String value, Profanities profanities) {
        if (Objects.isNull(value) || profanities.contains(value)) {
            throw new IllegalArgumentException("이름이 올바르지 않으면 등록할 수 없습니다.");
        }
        this.value = value;
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (!(o instanceof Name)) return false;
        Name that = (Name) o;
        return value.equals(that.value);
    }

    @Override
    public int hashCode() {
        return Objects.hash(value);
    }
}

위와 같이 Name에서는 인터페이스를 참조하고 있어서(=저수준 모듈에 의존하고 있지 않아서) 외부 API 송수신 로직이 어떻게 바뀌든 영향이 없다.

4. 결국 클린 아키텍처

그래서 결론은 클린 아키텍처에서 주장하는 핵사고날 아키텍처가 가장 이상적인 형태라고 강의에서는 정리하고 있다.

대원칙은 ‘외부의 변화로부터 자유롭다’ 가 클린 아키텍처의 대원칙이다.

외부에서는 내부를 알지만 내부에서는 외부를 전혀 모르는 것이다. 클린 아키텍처는 나중에 책을 읽으면서 따로 포스팅으로 정리해볼 필요성이 있는 것 같다.