도메인 주도 설계

DDD(Domain Driven Design)

​

​

​

2017/10/19

Slack : @ninetin

​

​

난 누구?

​

​

​

​

​

​

서일구 (ILGU SEO)

• 2013년 도일(渡日) 올해로 4년
• 와서 한 것 Java(웹), C#(클라이언트 프로그램), 잡다한 것(서버관리, 환경구축)

기타 등등

​

아젠다

1. DDD(Domain Driven Design)가 뭐야?

​

• DDD하는 방법?

​

• 부록

​

아젠다

• DDD(Domain Driven Design)가 뭐야?

​

• DDD하는 방법?

​

• 부록

​

DDD(Domain Driven Design)가 뭐야?

“하나의 팀에서 하나의 언어로”

​

• Eric Evans

DDD(Domain Driven Design)가 뭐야?

​

• 도메인(Domain)은 웹 도메인 말고...

소프트웨어로 해결하고자 하는 문제 영역을 뜻함 = 요구사항

​

• 시스템을 구현하기 위해 특정 기술이 아니라 도메인과 그 로직에 초점을 두어야 함

​

• 사용자(고객), 개발자가 참고할 수 있는 공통 언어를 형성해야 함

DDD(Domain Driven Design)가 뭐야?

​

​

​

​

​

DDD(Domain Driven Design)가 뭐야?

DDD(Domain Driven Design)가 뭐야?

​

• 도메인(Domain)은 웹 도메인 말고...

소프트웨어로 해결하고자 하는 문제 영역을 뜻함 = 요구사항

(제대로 했을터...)

​

• 시스템을 구현하기 위해 특정 기술이 아니라 도메인과 그 로직에 초점을 두어야 함

(제대로 했을터...)

​

• 사용자(고객), 개발자가 참고할 수 있는 공통 언어를 형성해야 함

(제대로 했을터...)

DDD(Domain Driven Design)가 뭐야?

이러한 문제를 탈피 하고자 나온 노력

DDD(Domain Driven Design)가 뭐야?

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

추상화를 거쳐서 객체로 만든다. = 객체지향(OOP)

​

DDD(Domain Driven Design)가 뭐야?

​

​

​

​

​

​

​

​

DDD도 어찌보면 객체지향(OOP)의 아류

​

DDD(Domain Driven Design)가 뭐야?

​

​

​

​

​

​

​

​

컴퓨터 소프트웨어 개발의 구조적 패턴들

​

DDD(Domain Driven Design)가 뭐야?

DDD(Domain Driven Design)가 뭐야?

​

​

​

​

​

​

​

​

​

왜 달라지는가? 뭐가 문제인가?

DDD(Domain Driven Design)가 뭐야?

소프트웨어와 도메인 사이에는

도메인

(요구사항)

모델

소프트웨어

DDD(Domain Driven Design)가 뭐야?

도메인

(요구사항)

모델

소프트웨어

DDD(Domain Driven Design)가 뭐야?

종종 이 모델을 세분화 하면서

모델

분석

설계

DDD(Domain Driven Design)가 뭐야?

서로간의 인식의 차이 가 발생한다

＝

아젠다

• DDD(Domain Driven Design)가 뭐야?

​

• DDD하는 방법?

​

• 부록

​

DDD하는 방법?

적용할때 고려할 점

​

• DDD는 조금씩 발전시켜 나가는 Agile 방식이 더 적합

​

• DDD는 절차적 언어로도 가능 그러나 책임을 분할하는 객체지향 언어에 더 적합

​

• DDD 모델은 UML로도 가능 그러나 양이 많아 지거나 행동, 제약사항 등의 표현에 한계

DDD하는 방법?

구현대상

모델링

구현

DDD하는 방법?

​

• 도메인이 제공하는 기능(동작 일 수도 있고, 고유의 값 일 수도 있음)

-난다.

-쏜다.

-변신한다.

​

• 도메인의 데이터 구성(동작에 필요한 변하는 값)

-다리길이

-팔 길이

-뿔 길이

DDD하는 방법?

​

​

​

​

​

​

​

​

​

• 도메인의 기본요소를 잘 생각하자(도메인이 제공하는 기능, 도메인의 데이터 구성)
• 모델링이 처음 한번에 끝나지 않는다. 여러사람이 늘 검증해야 한다.(ex:디렉터, 아키텍트,개발자,디자이너)
• 해당 도메인의 정수(핵심)만 표현되어야 한다!
• 언제까지? 모르는 사람이 봐도 대상 도메인을 이해할 수 있을때 까지
• 개발때는 그 도메인 모델만 바라보자!!

​

​

DDD하는 방법?

Check List!

​

​

• 모두가 이해하는 도메인 모델이 존재하는가? (Yes / No)

​

• 모든 이해 당사자가 의사소통에 공통적인 언어(정의된 용어, 즉 Ubiquitous Language)를 사용하는가? (Yes / No)

​

• 소프트웨어가 Model Driven Design(모델 수준으로 추상화 되어 코드와 연동하는) 방식으로 개발되고 있는가? (Yes / No)

끝?

감사합니다…？

아젠다

• DDD(Domain Driven Design)가 뭐야?

​

• DDD하는 방법?

​

• 부록

​

부록

부록

● 엔티티 (Entity)

- 식별자를 가지며 영속성이 필요한 객체(ex:DB, Java Bean)

​

● 값객체 (Value Object)

- 식별자가 없으며 영속성이 필요없는 객체(ex:돈, 포인트)

- 수정할 수 없고 필요한 만큼 복제하여 전달하여 사용

​

● 서비스 (Service)

- 특정 엔터티나 값객체에 속할 수 없는 도메인의 개념 표현

- 주로 여러객체에 걸쳐서 일어나는 행위를 담당

- 상태정보를 관리하지 않음

부록

● 집합 (Aggregation)

- 객체의 소유권과 경계를 정의

- 데이터를 변경할 때 하나의 단위로 간주되는

- 외부에서 접근할 수 있는 단하나의 창구인 root를 가짐

● 팩토리(Factory)

- 복잡한 객체 생성(ex : Aggregation)의 절차를 캡슐화

- 단순한 경우라면 생성자를 사용

​

● 리파지토리(Repository)

- 객체의 저장을 담당

- 이미 존재하는 도메인 객체의 참조를 얻는 로직을 캡슐화

진짜 끝