도메인 중심 설계(DDD)와 데이터 중심 설계

다섯번째 아티클이다!!
오늘은
🐻 도메인 중심 설계와 데이터 중심 설계 기법의 개념/특징/차이점 등등을 정리하고
🐻 왜 DDD가 이리 유명하게 되었는지
에 대해 고민해 보는 시간을 갖으려 한다.
오늘도 힘차게 가보자!

Domain?

우리가 오늘 살펴볼 개념인 DDD는 Domain Driven Design의 약지이다. 우선 도메인이 무엇인지 부터 살펴보자.

우선 도메인의 사전적 정의는

A domain is a field of study that defines a set of common requirements, terminology, and functionality for any software program constructed to solve a problem in the area of computer programming, known as domain engineering.

컴퓨터 프로그래밍으로 문제를 해결하기 위해 만들 소프트웨어 프로그램을 위한 요구사항, 용어, 기능을 정의하는 학문 영역이 도메인 공학이다. - 위키백과

소프트웨어 관점에서 도메인은 사용자가 사용하는 것으로 소프트웨어로 해결하고자 하는 문제 영역을 말한다. 간단히 말하면 비지니스 영역이라고 보면된다.

그럼 도메인 주도 설계란 (DDD)

DDD는 글자 그대로 도메인을 중심으로 하는 개발 방식을 말한다. 즉 도메인에 관련된 문제를 해결하는 것을 말한다. 복잡한 도메인을 해결하는 것을 높은 우선순위로 하여 서비스를 만들어 나가는 방법이라고 볼 수 있겠다.

DDD의 특징

1. 도메인의 모델과 로직에 집중
   데이터가 중심이 아닌 도메인의 모델과 로직을에 집중한다.
   업무 용어를 통일한다는 것이다. 분석자국, 설계, 구현에 이르기까지 통일된 방식으로 커뮤니케이션한다.

2. Ubiqutious Lamguage, 보편적 언어 사용
   동일한언어와 표현으로 구성된 단일화된 언어 체계를 사용한다.

3. Software Entity Domain간 개념 일치
   분석모델과 설계가 다을고 그것과 코드가 다른 구조가 아니라 도메인 모델 붙 코드까지 함꼐 움직이는 구조의 모델을 지향하고 있다.

4. 높은 응집도와 낮은 결함도
   각 도메인은 서로 협력하지만 책임과 역할이 명확하여 높은 응집도와 낮은 결합도를 갖는 상태를 지향한다. 이를 통해 변경과 확장에 대해 유연한 코드를 작성 가능하다.

DDD 적용 방법

먼저 DDD적용 방법을 알아보기전에 용어 먼저 정리해보겠다!

• 도메인 모델: 비지니스 도메인의 개념, 규칙, 데이터를 추상화한 모델. 도메인 모델을 통해 비즈니스 로직을 명확하게 표현하고, 시스템의 설계와 구현에 반영합한다.
• 유비쿼터스 언어는: 개발자와 도메인 전문가가 공유하는 공통 언어로, 도메인 모델의 개념과 용어를 일관되게 사용한다. 왜냐하면 유비쿼터스 언어를 통해 일관된 커뮤니티 방식을 사용하여 의사소통의 효율성을 높이고, 도메인에 대한 이해를 깊게 할 수 있다.
• 바운디드 컨텍스트: 도메인이 적용되는 특정한 경계를 정의하는 것으로, 시스템 내에서 도메인 모델의 적용 범위를 명확하게 한다. 바운디드 컨텍스트를 통해 도메인 모델의 경계를 명확히 하고, 모델 간의 충돌을 방지할 수 있다.
• 애그리거트는 도메인 모델 내에서 일관성을 유지해야 하는 데이터와 객체의 집합으로, 도메인의 복잡성을 관리하는 데 중요한 역할을 한다.도메인 모델의 일관성을 보장하고, 복잡한 비즈니스 로직을 효과적으로 관리할 수 있다.
• 컨텍스트 맵: 바운디드 컨텍스트 간의 관계를 말한다.
• 리포지터리: 필요한 객체를 물리적인 저장소에서 구하거나 저장할 때 리포지터리를 사용한다.

1. DDD에서 말하는 도메인,서브도메인,바운디드컨텍스트를 구분하고 정의
2. 이를 바탕으로 Aggregate,Entity,Value Object,Repository 등을 구현 하기
3. 이에 적합한 아키텍처를 결정하고 개발하기

이때 DDD의 특징에서 봤듯이 팀 구성원이 모두 이에 대한 합의를 이루어야 하고, DDD에 대한 지식들이 학습되어 있어야 한다.

데이터 중심 설계는 뭔데?

데이터베이스의 구조와 데이터의 흐름을 중심에 놓고 설계하는 방식을 말한다.
데이터 주도 설계 에서는 객체 자신이 포함하고 있는 데이터를 조작하는 데 필요한 행동을 정의한다.

데이터 중심 설계의 특징

1. 데이터베이스의 설계를 중심으로 개발을 진행한다.

2. 캠슐화 위반
   데이터 중심 설계는 외부에 대부분 구현이 노출된다.
   데이터 중심 객체 설계는 객체와 다른 객체간 어떤 협력과 책임이 있는지 고려하지 않고 오직 어떠한 데이터가 필요한지에만 집중한다. 이렇게 되면 개발자는 앞으로 어떤 데이터로 협력 될지 모르기 때문에 과도하게 접근자, 수정자를 추가하게 된다. 이는 캡슐화를 위반하기 쉽게 되는 상황을 만드는 것이다.

3. 높은 결합도와 낮은 응집도
   내부 구현이 퍼블릭 인터페이스에 노출 되며 이 때문에 다른 객체들과 강하게 결합되게 된다. 이로 인해 객체의 내부 구현이 변경될 때 이 인터페이스에 의존하는 모든 객체들이 함께 변경되므로 높은 결합도를 유지하게 된다.
   응집도는 모듈 내의 구성 요소 간의 밀접한 정도를 의미하는데, 한 모듈이 하나의 기능(책임)을 갖고있는 것은 응집도가 높은 것이고, 한 모듈이 여러 기능을 갖고 있는 것은 응집도가 낮은 것이다. 과도한 접근을 허용하게 되어 여러 객체에서 접근하여 로직을 작성하다 보니 하나에 객체에 많은 접근자가 있을 것이고 아를 수정하려고 하면 다른 객체에 영향을 미치게 한다는 것이다. 결국 캡슐화를 위반하여 파생되는 문제 중 하나이다.

데이터 중심 설계와 DDD 차이점

코드로 한번 비교해보자.

(appleg1226님의 티스토리 블로그를 많이 참고했습니다!)

데이터 중심 설계이터 중심 설계

데이터 중심의 코드에서는 보통 다음의 패턴으로 개발이 많이 이루어진다.

public void createReservation(User user, Seat seat, LocalDateTime startTime, LocalDateTime endTime){
    Reservation reservation = new Reservation();
    reservation.setUserId(user.id);
    reservation.setSeatId(seat.id);
    reservation.setStartTime(startTime);
    reservtiion.setEndTime(endTime);
    this.reservationRepository.save(reservation);
}

위 코드를 참고하면 getter와 setter를 통해서 비지니스 로직을 처리하고 있음을 볼 수 있다.

DDD
DDD에서는 위와는 다르게 Entity에 직접 영향을 미치는 코드를 도메인 영역이라는 부분으로 감춘다.이를 통해 름을 이전과 다르게 더 직관적으로 읽을 수 있도록 도와준다.

public void makeReservation(User user, Seat seat, LocalDateTime startTime, LocalDateTime endTime){
    this.reservationCommandService
        .makeReservation(user, seat, startTime, endTime);
}

만약 예약시작 시간을 변경하고 하면
기존 데이터 중심 설계에서는

reservation.setStartTime(start);

와 같은 코드를 사용했을 것이다.

하지만 DDD에서는 아래와 같은 인터페이스를 두고 시작 시간을 변경할 것이다.

public interface Reservation{
    public void changeStartTimeTo(LocalDateTime start);
}

reservation.changeStartTimeTo(start);

코드를 통해서 봤듯이 DDD를 적용하면 코드에 대한 가독성과 로직의 흐름을 직관적으로 파악할 수 있다.

왜 DDD야?

DDD이 인기 있는 이유를 나의 생각으로 하자면
1)DDD는 복잡한 비즈니스 문제를 효과적으로 해결할 수 있기 때문이다. 복잡해지는 현대의 비지니스 환경과 소프트웨어 시스템을 체계적으로 다룰 수 있는 것이 DDD이다.
2) DDD는 비즈니스와 개발 간의 갭을 줄이고, 유비쿼터스 언어를 통해 팀 간의 의사소통을 원활하게 하여 협력을 증대시키고, 복잡한 시스템을 관리 가능한 단위로 나눠 유지보수와 확장성을 높인다.

이 두가지 이유가 DDD가 인기있는 이유인 듯하다. 모든 소프트웨어 프로젝트에 대한 해결책이라고는 말 못하겠지만 복잡하고 변화가 많은 비즈니스 도메인에서는 효율적인 방법론인것 같다!!

정리하면서...

사실 DDD라는 개념에 대해 '공부'한 것은 처음이다. 정리하면서 느낀 것인데 하나의 글에만 그 내용들을 정리하기에는 나의 실력이 부족하고 내용이 방대한 것 같다(?) ! 수박 겉핥기 식으로 공부를 했으니 좀 더 자세하게 공부하여 정리해햐지~ 또 TDD 나 BDD 같은 다른 개발론도 공부해 보고싶다!!
그리고 https://helloworld.kurly.com/blog/road-to-ddd/ 를 이 글을 정리해보면서 봤는데 매우 흥미로운,,,,😯

참고
https://appleg1226.tistory.com/40
https://biggwang.github.io/2019/07/29/OOP/%EA%B0%9D%EC%B2%B4%20%EC%84%A4%EA%B3%84%20%ED%95%A0%20%EB%95%8C%20%EB%8D%B0%EC%9D%B4%ED%84%B0%20%EC%A4%91%EC%8B%AC%EC%9D%B4%20%EC%95%84%EB%8B%8C%20%EC%B1%85%EC%9E%84%20%EC%A4%91%EC%8B%AC%EC%9C%BC%EB%A1%9C%20%ED%95%B4%EC%95%BC%20%ED%95%98%EB%8A%94%20%EC%9D%B4%EC%9C%A0/
https://www.youtube.com/watch?v=4QHvTeeTsj0