태태개발일지 - 도메인 주도 설계의 사실과 오해 후기(조영호 강사님)

 

 

Next Step에서 진행하는 DDD 강의를 듣게 되었다. 수강료는 18만원으로 2일에 거쳐서 4시간씩 진행되는 강의였다.

 

수강 이유

프로젝트에서 클린 + 레이어드 아키텍처로 진행하다가 도메인을 나눌 때 어떻게 나누어야하는지 궁금했고, DDD라는 개념을 접했는데 이에 대해서 더 알고싶어 수강을 하게 되었다.

 

강사님

조영호 강사님이다. 객체지향으로 유명하시고, 이분의 인프런 강의를 수강한 상태로 진행 되었다.

 

시작

DDD와 객체지향에 대해 오해가 있는 것 같다.

 

 

DDD를 사용하면 문제가 해결된다.?

DDD 너무 어려워 안할래?

 

객체지향과 도메인주도 설계의 차이점

 

객체지향

알고리즘과 데이터의 조화를 통해 작은 문제를 해결하는 것이다.

 

도메인 주도 설계

(디자인패턴, 단위테스트, 아키텍쳐) 이러한 기술들을 비지니스로직까지 끌고가서 결정하자는 의미이다.
단지 기술적인 요소가 아니라 도메인을 중심으로 기술을 택하자는 것이다.

 

 DDD

목표
사용자들이 겪는 문제를 해결하는 것이 목표.

 

기술이 목적이 되면 안된다. 기술의 목적이 도메인이여야한다고 한다.

2003년 기술에 대한 집착이 심했던 시기에 DDD는 Domain을 중심으로 여러 기술들을 잘 엮었기 때문에 혁명이라고 불렸다.

 

 

DDD에 있는 부분중 이걸 적용해 볼까? 이게 맞나? 가 올바른 생각이다.
DDD는 이거다라는 생각을 가진다면 거기서 부터 잘못된 것이다.

 

 

 

 

첫장

동작하는 도메인 모델 만들기가 나온다.

도메인: 사용자가 프로그램을 사용하는 주제의 영역이다.

 

음식 배달을 예로 들면, (어디서 부터 얻어디까지 고민하고 개발하겠다)를 생각하는 과정을 도메인 모델링이라는 것이다.

메뉴,주문,결제 는 software로 개발가능하지만, 조리, 배달은 software로 구현이 불가능하다. 를 생각하는 것이 모델링이라고 한다.

이렇게 단순화 하는 것의 창출물을 도메인 모델이라고 한다.

software = 사용자의 문제를 해결하기 위한 것이다.

 

즉 Domain이란 고민할 범위라는 것이다.

 

 동작하는? 의 개념은 무엇인가.
모델링을 끌고가서 동작하게 하는 것이다. 

 

 

정확하게 말하자면 과거에는 모델을 설계하고 그 설계를 버린 후 코드로 적용했지만,

이제는 설계를 코드까지 끌고가서 도메인 모델 = 코드로 보는 것이다.

모델 코드 설계 세가지 중 하나가 바뀌면 바뀌어야한다는 것이다.

 

 

지식탐구

개발자와 도메인 전문가 사이의 활발한 논의를 거쳐 유용한 도메인 모델을 도출하는 것이다.

 

 

도메인 전문가도 개발자가 이해할 수 있도록 해야하고, 개발자도 도메인 전문가가 알수 있도록 해야한다.

이를 유비쿼터스 언어를 활용하여 진행해야하고,

유비쿼터스 언어로 개발을 해야한다는 뜻이다.

 

객체지향

사실 객체지향은 프론트단에서 시작이 되었다.

ex) 화면을 클릭했을 때 객체가 어떤 행동을 하고 ..

 

웹이 나오기 시작했고, 이를 쓰리티어로 사용하게 되기 시작했다.

 

EJB의 등장

EJB에서 객체를 만들었을 때 다른 시스템에 배포하면 통신이 되게 하고싶었다.

이를 코드가 infra에 종속이 되었다고한다.

 

또한 EJB는 인터페이스를 강조했다.- > 스프링과 구조는 비슷하지만, EJB는 이를 강조했다.

(관심사가 섞이게 된다는 뜻이다)

 

관심사를 분리하는 이유:

개발은 다 자르는 것이다. (본인이 고민해야하는 관심사만 고려하기 위해서)

 

EJB의 한계

분산의 한계를 느끼고,

도메인이 기술을 주도해야하고, 기술이 도메인을 주도하면 안된다. 모델을 그대로 구현하자. 라는 생각을 가지게 되었고,

 

 

빌딩블록

빌딩블록:  구현 가능한 도메인 모델을 구성하는 요소들의 목록을 뜻하는 것이다. 

 

카테고리를 분류하고 싶다면,  어떤걸 단순하게, 어떤건 복잡하게 특성에 맞게 분류할 까 생각해야한다.

특정한 복잡성 이라는  가이드에 맞춰서 구현하면 좋다.

이를 빌딩 블록이라고한다.

 

 

도메인을 표현하기 위한 빌딩 블록:

연관관계, 엔티티, 값 객체, 서비스 ..

 

생명주기를 관리하기 위한 빌딩블록:

어그리거트, 리파지토리, 펙토리

 

어그리거트

사람들이 에그리거트를 잘못 이해하고 있다.

여기선 불변식이라는 개념이 나오는데. DDD로 도메인 레이어를 구현하고 있다는 뜻 = 불변식을 만족하고있다는 뜻.

 

도메인관점이 아닌 데이터 관점 => 수집된 데이터만 바뀐다 => 불변식 위반

 

불변식을 막기위해 묶은 것을 어그리게이트라고한다.

여러개의 객체의 상태를 보고 판단한다. 하지만 데이터 관점으로만 하면 안된다.

즉 트랜잭션의 단위와 동일하다고 보면 된다.

객체를 묶어야해~ 그걸 Domain단위로 묶어야해 => 그것이 DDD이다.

 

도메인모델 패턴 => 도메인 레이어를 객체지향적으로 짜는 것

도메인모델 => 도메인을 추상화 시켜서 분리한 것.

POJO => new로 객체를 만들었을 때 그상태이다.

 

 

애자일

프로젝트를 진행하면서 점점 배우고 개선된다.

 

애자일의 궁극적 목표는 변경이 생겼을 때 빠르게 대응하자 이지 일을 빠르게 하자가 아니다.

xp와 애자일의 key는 우린 어짜피 바뀌어 변경을 수용하자 이다.

이 상태에서는 피드백이 가장 중요하다.

 

설계는 코드를 이미 짠 후 배치를 하는 것이 설계이지, 코드를 모르고 설계하면 고민하다가 끝나게 된다.
즉 리펙토링을 하며, 개발을 하자는 것이다.

 

 

DDD의 일부인 이유

도메인 모델이 코드 그자체가 된다면, 설계 모델 코드중 하나만 바뀌어도 지속적으로 수정이 되어야하고, 이 과정을 통해 DDD가 완성된다는 것이다. 반복적이고 점진적인 작업이라는 것이다.

이런 상황에서 중복이 보이면 추상화로 올리는 작업 

 

DDD모델 종류

DDD는 모델이 하나여야하나? (x) 여러개여야한다.

하지만 중요한 곳에 집중해야한다.

 

ex) 팀을 나누기 시작했는데 코드가 동일한데 팀이 나뉘면 문제가 생긴다. 즉 코드를 나눠야하는데  컨텍스트에 따라서 찢어야한다. 이를 바운디드 컨텍스트라고한다.

 

 

DB까지 나누는 것이 편하고,

Domain에 영역을 주는 것을 바운디드 컨텍스트라고 한다.

 

서로다른 바운디드 컨텍스트 개념의 의미가 다를 때 번역하는 것을
컨텍스트 맵이라고한다.

 

 

도메인은 하위 도메인으로 나뉘게 되고,

이를 서브 도메인이라고한다.

 

도메인중 가장 중요한 코어도메인,

주니어개발자나 외주를 맡기는 제네릭 서브 도메인

코어 도메인을 지원하는 지원 도메인이있다.

 

현재

전술적패턴 & 전략적 패턴으로 나뉜다.

 

바운디드 컨텍스트:  솔루션 공간

핵심도메인,일반: 문제 공간이라고한다.

 

도메인 이벤트

하나의 에그리거트와 다른 에그리거트가 트랜잭션으로 엮기위해 이벤트를 발행하는 것이고,

 

이벤트 소싱 

DB는 최정만 저장하지만 그 과정을 궁금해할 때가 있는데 이벤트 스토어에 저장하면된다.

 

 

이번주 일요일에는 어그리거트와 엔티티 값객체등 코드를 통해서 정확하게 이해하는 과정을 수강하러가서 너무 떨린다.