[NHN FORWARD 22]DDD 뭣이 중헌디?

https://www.youtube.com/watch?v=6w7SQ_1aJ0A 

 

NHN Dooray의 협업서비스개발그린팀 정명주 님의 발표를 요약한 내용입니다.

 

DDD에 대한 오해

DDD는 Domain Driven Design의 약자입니다.

3년 전에 DDD 전략적 패턴에 대해 발표를 하였고 여기에만 함몰되는 경우가 많습니다.

 

AS-IS

이번 도면 서비스가 중요하니까 DDD로 개발하자고~

Aggregate, Domain-Event, Repository를 이용해서 도메인 모델을 만들어서~

 

TO-BE

이번에는 도면 도메인이 중요하니까 전체적으로 DDD(전략적 설계)를 통해서 전체 관계를 다시 정리하고, 지식 탐구 세션을 통해서 영향받는 모델을 다시 살펴보자고~

 

AS-IS처럼 이야기하는 것보다는 TO-BE처럼 이야기하는 것이 좋습니다.

 

DDD에서 전술적 패턴보다는 전략적 설계가 중요합니다.

우리가 해결해야 할 도메인에서 무엇이 중요한지 알아내는 것이 중요합니다.

 

전략적 설계 VS 전술적 설계

전략적 설계란 전쟁에서 전략을 말하며 전반적인 설계관점에서 진행됩니다.

주요 전략으로는 Bounded-Contexet, Ubiquitous-Language 등이 있습니다.

 

전술적 설계란 전투에서 전술을 말하며 특정 Bounede-Context의 설계관점에서 진행됩니다.

주요 전술으로는 Aggregate, Domain-Event 등이 있습니다.

 

전략적 설계

비즈니스 도메인과 문제 도메인으로 나누어 보겠습니다.

회사의 전체 비즈니스 도메인에서 일부를 소프트웨어로 해결하고자 할 때 이를 문제 도메인이라 부릅니다.

예를 들어 인터넷에서 가장 빠르게 예매할 수 있도록 하고 싶은 경우에 인터넷 예매가 문제 도메인이 됩니다.

 

인터넷 예매라는 문제 도메인을 하위 도메인으로 나누고 핵심적인 내용과 지원하는 내용들을 구분합니다.

• 예매(핵심)
• 도면(지원), 상품(지원)
• 회원(일반)

 

핵심 도메인은 경쟁사에 의해 우위를 가져야 하고 복잡하고 구현 난이도가 높습니다.

여기서 말하는 핵심 도메인은 비즈니스 상황에 따라 계속 달라질 수 있습니다.

 

경쟁사에 비하여 도면이 중요해질 수 있고, 어떨때는 상품이 도메인이 핵심이 될 수 있습니다.

전략적 설계 시 유용한 도구

• use-case 분석
• 이벤트 스토밍
• Business Model 분석

지식 탐구와 커뮤니케이션이 중요합니다.

 

언제 어디서나 Ubiquitous-Language

도메인 전문가, 개발자, 기획자들이 머릿속에 정해진 단어사전을 항상 가지고 있어야 합니다.

같은 용어를 다르게 부르지 않습니다.

 

 

Bounded-Context

경계가 있는 문맥?

이름이 동일하지만 특정 Bounded-Context 안으로 들어가게 되면 명확한 의미를 가집니다.

회원 경계에서는 Account는 계정이지만 은행 경계에서는 Account는 계좌입니다.

 

 

공통적으로 Proudct를 사용하는 것이 아니라 Bounded-Context별로 관심사인 Product를 만들어서 사용합니다.

 

콘웨이의 법칙

소프트웨어의 구조는 해당 소프트웨어를 개발하는 조직의 구조를 따라간다.

개발하는 조직의 구조를 소프트웨어의 구조에 맞춘다.

• 예매 개발팀
• 회원 개발팀
• 도면 개발팀
• 상품 개발팀

 

Context-Map

서브 도메인들로 Bounded-Context가 나뉘게 됩니다.

https://www.youtube.com/watch?v=4QHvTeeTsj0

카카오 세미나에서 나온 Context-Map입니다.

upstream과 downstream으로 나누어 Map을 그립니다.

Publisher(=Upstream)

Subscriber(=Downstream)