1. DDD
정복기 1탄
@ jjo_ssoo

2. 정복기에 시작하기에 앞서
■ 처음 들었던 DDD에서의 Domain?
Domain이 설계의 중심?
관계형 데이터베이스에서 테이블의 각 속성이 가질 수 있는 값의 집합?
인터넷상에서 개인이 소유하고 있는 인터넷 주소?
각자 생각하는 Domain은 다 다를 것!
DDD에서의 Domain은 다르다!

3. DDD ?
What is the “Domain Driven Design”?

4. Domain-
Driven-
DESIGN
저자 : Eric Evans
이 책의 한줄 평
DDD를 공부하는 이들에게 성서와
같은 존재 (해석도 여럿이다.)
by Gyuwon Yi

5. DDD 준비 단계
개발은 일정한 반복주기를 가지고,
반복주기를 토대로 진행되야 한다.
Domain 전문가와 밀접한 관계에 있어야 한다.

6. DDD
복잡한 도메인을 다뤄야 하는 SW 프로젝트에 박차를 가하는 것을 목표로 삼는
사고방식이자 우선순위의 모음
소프트웨어는 도메인의 핵심 구성과 각 구성요소를 담고 있어야 한다.
이렇게 도메인과 조화된 소프트웨어를 만드는게 DDD의 목적

7. STEPs
Analyze
Domain
Domain
Ubiquitous
Language
Bounded
Context
Bounded
Context
Context Map Shared Kernel Etc)
Define Entities,
Aggregates,
Services
Entities Value Object Aggregates Services Etc)
UI Application Domain Layer Infrastructure
Layerd
Architecture

8. ANALYZE DOMAIN
DOMAIN으로 부터 얻는 것

10. Domain
사용자가 프로그램을 사용하는 대상영역
SW는 도메인의 문제를 해결하기 위한 수단
하나의 도메인은 하위 도메인으로 나눌 수 있다.

11. DOMAIN MODEL
도메인의 구성요소를 개념적으로 표현한 것
SW 전문가와 도메인 전문가가 만드는 것
도메인에 대한 이해가 필수!
어떤 특정한 다이어그램이 아니라 다이어그램이 전달하고자 하는 아이디어

12. DOMAIN MODEL
모델은 도메인 지식의 정수만을 뽑아 낸 것
모델은 팀 구성원이 사용하는 언어의 중추
모델과 핵심 설계는 서로 영향을 주며 구체화된다.

13. Ubiquitous Language
서로의 용어를 이해해야만 한다!
도메인 모델을 만들기 위해선 모호함이 없어야 한다.
만들어진 Ubiquitous Language는 보관이 필수!

14. Ubiquitous Language
도메인 모델 용어
Bounded Context 이름
기술적 디자인
패턴
DDD에서 소개하는 여러 패턴 이름
대규모 구조 용어
기술적인 용어
개발자가
이해하지
못하는 업무
관련 용어
모든 이들이
사용하지만 설계에
나타나지 않는 업무
관련 용어
(모델에 속하는 후보)
설계의 기술적 측면

15. Ubiquitous Language
설계의 세부사항은 코드에 담긴다.
문서는 코드가 이미 잘 하고 있는 것을 하려고 해서는 안된다.
문서는 유효한 상태를 유지하고 최신 내용을 담고있어야 한다.

16. QUICKLY MODELING
From Domain

17. Modeling Example
영화 예매 시스템
1. Reservation은 영화 정보ID, 좌석 정보, 요금정보를 갖는다.
…
Reservation : 영화 예매 정보, Movie: 영화 정보, Sitting : 좌석 정보, Rate: 요금 정보등

18. Modeling Example
Reservation Model (이거보다 훨씬 풍성해져야 한다)
Reservation
ID
MovieID
Sitting
Rate

19. Enitity
소프트웨어가 여러 과정을 거치는 과정에도
동일한 값을 유지하는 식별자를 지닌 유형의
객체
“Entity의 정체성에 초점을 맞추어야 한다.
의미에 따라 Entity를 분류한다면 모델이
더욱 투명해지고 구현은 견고해질 것이다.”
By Eric Evans

20. Value Object
개념적 식별성이 없는, 어떤 특징을 묘사하는
객체
한번 만들어 지면 바뀌지 않는 객체
값 자체에만 의미가 있다.

21. Aggregate
일관성을 공유하는 데이터 집합
일관성을 유지해야될 객체들을 묶어 놓은 것
Root Entity : 접근 범위에 있는 가장 상위
Entity
Aggregate은 Root Entity만을 통해
외부에서 접근 할 수 있다.

22. Aggregate
필요성
연관 관계를 줄이면서 복잡도가 감소한다.
많은 도메인 모델을 간단하고 이해가능한
수준으로 만들어 줄 수 있다.

23. Modeling Example
Reservation Aggregate
<<Value Object>>
Rate
…
<<Entity>>
(Root)
Reservation
Id: Guid
MovieId: Guid
Sitting : Sit
Rate : Rate
<<Value Object>>
Sit
…

24. Effective Modeling by Eric Evans
모델과 구현의 연계
모델을 기반으로 하는 언어 정제
풍부한 지식이 담긴 모델 기반
모델의 정제
브레인 스토밍과 실험
지속적인 학습

25. DDD를 왜 해야하는지?
놓치기 쉬운 이유

26. Why DDD?
DDD 발표를 준비하면서 많은 내용들의 글을 보았지만 DDD에 대한 요소들의 설명은 많이
찾아 볼 수 있었다.
하지만… 요소들의 설명들만큼 찾기 힘들었던 DDD의 존재이유….
덕분에 Eric Evans 님의 말을 이해하려고 노력함

27. Eric Evans 가 말한 Domain
하나의 도메인은 세상의 어떤것!
우리가 이해하기 위해 혼신의 힘을 다해야만 하는 가장 중요한 부분!
힘있고 유연한 소프트웨어를 만들게 해준다!

28. 내가 생각하는 DDD의 장점
3. 어느 분야나 트렌드는 변한다.
DDD로 잘 설계 되어있는 소프트웨어는 변하는 Trend에 재빠르게 진화할 수 있는
소프트웨어가 될 수 있다.
1. 복잡한 설계를 잘 나누는 데에 중점을 둔다.
2. DDD는 도메인 전문가와 소통을 중요하게 여긴다.
그래서 도메인이 무엇을 하고자 하는지에 명확해지기를 DDD가 유도한다.

29. TO BE CONTINUED
2탄 Bounded Context: 모델 무결성에 관하여

30. THANK YOU
DDD 정복기 1탄 끝
@ jjo_ssoo