DDD란 무엇인가?

DDD란?

DDD는 Domain-Driven Design의 약자로 도메인에 의한 설계로 해석해 볼 수 있습니다.

"도메인이란 무엇일까?"는 조금 뒤에 다시 알아보도록 하며..

왜 DDD란 개념이 등장하게 되었을까요?

 

왜 사람들이 DDD를 추구하려고 할까?

DDD에 관련된 서적들도 많고 세미나에서도 종종 등장하며 주변 동료들도 이야기하기도 합니다.

"왜 사람들이 DDD를 추구하려고 할까요?"라는 질문에 대답한다면 제가 이해한 바로는 소프트웨어의 복잡성과 의사소통의 비용을 줄이기 위해서입니다.

 

 

이때 소프트웨어를 구현하기 위해서는 보통 크게 두 가지 문제에 부딪히게 됩니다.

1. 사용자가 제시하는 복잡하고 자주 변화하는 요구사항(필수적 복잡성)
2. 성능이나 협업에서 발생하는 기술적인 어려움(부수적 복잡성)

 

이때 DDD는 필수적 복잡성을 줄이는 것이 목적입니다.

 

예를 들어 은행이라고 한다면 대출을 발행하기 위해 매우 복잡한 요구사항이 필요할 수 있습니다.

신용 평가 조회를 해야 하고, 각종 서류들이 제출되어야 하며, 현재 채무 등이 없어야 하고... 등등등

 

"도메인이란 무엇일까? 에 다시 대답한다면 도메인은 소프트웨어의 문제를 해결하고 하는 비즈니스의 핵심가치를 담고 있는 개념입니다.

 

이때 소프트웨어는 매우 다양한 문제를 해결할 수 있기 때문에 이커머스, 은행, 미디어 등 매우 다양한 도메인들이 존재합니다.

 

 

DDD는 항상 좋을까?

애플리케이션이 데이터 중심이며 순수한 CRUD 솔루션에 잘 맞는다면 DDD가 필요하지 않을 수 있습니다.

간단한 프로젝트나 도메인이 그리 복잡하지 않은 경우에는 DDD가 오히려 과도한 설계를 초래할 수 있습니다.

 

 

내가 느끼는 DDD에 대한 진입장벽

• 유비쿼터스 언어, 전술적 설계, 전략적 설계
• Aggregate, Entity, Value Object 

 

위의 개념들에 대해 모두 알아야 DDD를 할 수 있을 것만 같은 느낌이 듭니다.

 

 

일반적인 데이터 중심 설계

1. DB를 설계한다.

2. 이를 토대로 Java 패키지를 구성한다.

3. Service에서는 CRUD 로직을 감싼 메서드를 만들거나 JPA Repository를 사용한다.

4. Controller 또는 Sevice에서 이를 조합하여 API를 제공한다.

 

 

도메인 중심의 설계

1. 도메인 / 서브도메인/ 바운디드 컨텍스트를 정의한다.

2. 이를 토대로 Entity, Value Object, Aggregate를 도출해 낸다.

3. 이를 토대로 Java 패키지를 구성한다.

4. 어떤 아키텍처를 도입할 것인지 결정하고 개발한다. (레이어드 혹은 헥사고날 등)

 

 

어떻게 하면 소프트웨어의 복잡성과 의사소통의 비용을 줄일 수 있을까?

 

https://yoonbing9.tistory.com/121(같은 용어를 사용하지만 다르게 이해할 수 있다.)

1. 유비쿼터스 언어 사용

유비쿼터스 언어를 번역하면 언제 어디서나 사용되는 언어라는 뜻으로 회의, 기획, 디자인, 개발 등 프로젝트 내부의 언제 어디서나 사용되기 위해 정의된 언어입니다.

 

즉, 모든 직군이 같은 용어를 같은 생각으로 이해하고 있는 것을 의미합니다.

이렇게 되면 자연스럽게 의사소통의 비용이 줄어들게 됩니다.

그리고 개발자는 이런 용어를 자연스럽게 코드에 녹일 수 있으며 추후에 코드를 분석하고 이해하는 시간을 절약할 수 있습니다.

 

2. 비즈니스로직을 도메인 모델로 모으자

데이터베이스 위주의 개발을 하게 되면 서비스에는 흐름제어 로직밖에 없으며, 핵심 비즈니스들이 SQL 등에 존재할 수 있습니다.

 

또한 Service에 모든 비즈니스가 존재하는 경우라면 도메인 객체는 단지 속성값만 이용되는 정보 묶음의 역할만 하게 됩니다.

 

 

예시를 통해 알아보는 DDD

public class Player {
    private String name;
    private int points;

    // constructor, getters and setters
}

public void gainPoint(Player player){
	int points = player.getPoints();
	points++;
	player.setPoints(points);
}

getter와 setter를 통해 비즈니스 로직이 처리됩니다. (순수한 Date Transfer Object의 역할)

DDD에서는 위와 같은 코드를 Anemic(무기력한, 빈약한) Domain Model으로 부르며 경계합니다.

어떻게 보면 캡슐화가 깨져있다고도 볼 수 있을 것 같습니다.

 

 

DDD에서는 위의 비즈니스에 대한 내용을 도메인 영역(rich domain)으로 감춰버립니다.

public class Player {
    private final String name;
    private int points;

    public Player(String name) {
        this.name = name;
        this.points = 0;
    }

    public void gainPoint() {
        points++;
    }
}


public void gainPoint(Player player){
	player.gainPoint() //이제 이 함수자체도 필요없어질것같네요.
}

 

플레이어는 포인트를 득점하는 경우에는 point를 1점 증가시킵니다.

 

 

마무리

읽어볼 책

아직 이제 DDD를 공부해 보는 걸음마 단계이지만 "객체지향을 어떻게 잘 활용할 것인가?"가 핵심이라고 느껴집니다.

어려워 보이는 전술적 설계, 전략적 설계도 결국 DDD를 잘 활용하기 위한 도구들이라는 생각도 듭니다.

추가적인 학습으로는 "도메인 주도 설계 첫걸음"이라는 책을 읽어보면서 DDD에 대한 개념들을 정립해보고자 합니다.

 

 

 

참고자료

https://appleg1226.tistory.com/40

https://yoonbing9.tistory.com/121

https://incheol-jung.gitbook.io/docs/q-and-a/architecture/ddd

https://www.baeldung.com/java-anemic-vs-rich-domain-objects