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

회사에서 한창 리팩토링중하면서 패키지 구조를 바꿀일이 있어 DDD가 뭔지 찾아보다가ㅎㅎ.. 좋은 영상을 발견해 간단히 정리하면서 봤다.

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

---

DDD

• 전략적 설계 : 좀 큰 설계, 큰그림 > 얘가 본질임
• 전술적 설계 : 지엽적, 구체적인 도메인 모델 설계
• DDD는 비즈니스 도메인 요소가 약한 서비스에 어울리지 않는다.
• MSA와 세트가 아니다
• 얘는 구체적인 방법론이 아니다. 추상적인 철학이랑 접근법에 가까움 > 전략적 설계에 근간을 두고있음

그래서 전략적 설계가 뭔데?

• 비즈니스 도메인에서 소프트웨어를 통해 해결하고자하는 문제가 문제 도메인이다.
• 보통 문제도메인은 방대한 복잡성을 갖는 경우가 많음.
• 이러한 문제공간을 해결공간으로 바꾸는게 전략적 설계의 큰 흐름

도메인

• 영역 집합
• 비즈니스 도메인 + 문제 도메인을 말함
• 소프트웨어로 어떤 문제를 해결해서 가치를 창출하느냐?가 문제의 시작인 셈(예를 들어 티켓팅이 비즈니스 도메인이면 예메서비스가 문제도메인이 될수도 있는 셈)

문제 공간

• 문제를 해결해서 새로운 가치를 창출 > DDD의 진입점
• 그러기 위해서는 문제 도메인을 하위 도메인으로 나누는것부터 시작해야함
• 여기서 쓰이는 도메인들을 도메인전문가와 함께 쪼개야함
  • 그리고 가장 중요하고 복잡한 핵심을 구분해야함
  • 핵심 - 지원 - 일반으로 하위 도메인을 구분할 것
  • 중요한것과 중요하지 않은것을 나눠야함
  • 제일 중요한 부분에 리소스 투자를 해야함 > 이런건 인하우스 개발을 할 것

해결 공간

• 해결 공간에서의 지식탐구는 개발자가 해야함
• 해결 영역에서는 개발단계의 설계가 생각됨
• 문제 공간에서 도메인을 구분한것처럼 다시 하위 도메인을 구분지어야함

Big Ball of Mud

• 특별한 구조가 없는 아키텍처 스타일
• 딱히 안티패턴은 아님.. 그냥 전술 중 하나

하지만 이로인해 복잡성이 높아질때 브라운 필드 전략적 설계

브라운필드 소프트웨어 = 이미 구축된 소프트웨어

전략적 설계시 유용한 도구

• 사용사례 분석
• 이벤트 스토밍 : bottom up 분석
• 비즈니스 모델 분석

언제 어디서나 도메인 문맥내에서 유비쿼터스 언어로 소통한다.

전략적 설계 vs 전술적 설계

전략적 설계 과정 > 문제 공간에서 해결 공간으로 가야함. 어떻게?

Bounded-Context

• 경계가 있는 문맥
• 해결공간에서 모델의 경계
• Bounded-Context가 달라지면 유비쿼터스 언어도 달라진다.
• 모델의 무결성을 위한 경계(무슨얘기?)
• 모델이 모호해지는 순간 모델의 무결성을 지키기 위함

모델이 무결성의 예시

• 이름은 같은 다른 개념이 등장할때 > Bounded-Context로 경계를 나눠주면 모호해지지 않는다.
• 예를 들어 회원 도메인에서의 Account와 은행에서의 Account는 다른 개념이듯이
• 또다른 예시, 동일한 개념이지만 여러 문맥에 의존하는 개념이 있을 수 있다.
• 예매에서의 Product, 정산에서의 Product는 전부 물품에 대한 얘기가 맞다.
• 이때의 Product모델이 모든 컨텍스트에서 만족하려면 복잡하고 커질 수 있다.
• 컨텍스트별로 필요한 기능을 수행하는 모델이면 충분하다. (예매에선 예매가 가능한지만 알면되고.. 등등)> 해결할 문제를 위한 속성, 행위만 있으면 된다.

Bounded-Context와 하위 도메인

• Bounded-Context과 하위도메인은 일종의 집합 관계가 된다.
• 해결공간을 찾을땐 다양한 상황이 나온다.
• Bounded-Context가 여러개의 하위도메인을 가질수도있고, Bounded-Context별로 하위도메인이 여러개일수도있다.
• 레거시가 주로 여러개의 Bounded-Context에 하나의 하위도메인인경우고 트렌드는 반대다.
• 해결공간에서 각 Bounded-Context별로 전술을 선택하는것도 중요하다.
• 핵심 도메인을 선정하고 거기에 모든 리소스를 쏟아부어야하니까 전술선택이 중요하다.

콘웨이의 법칙

• DDD한다고 다 해결되나?
• 사실 소프트웨어 구조는 그거 개발하는 회사 구조 따라감..
• 개발하는 조직 구조를 소프트웨어 구조에 맞춰야한다.

Bounded-Context 매핑관계

• 기술적으로 최선의 선택을 할 수 있으면 좋겠지만 조직,정치,도메인 상황을 종합적으로 고려해서 판단한다.

Context-Map

• 해결공간을 표현하는 산출물
• 현재의 상태여야함

BBOM에서 진화하는 설계

• 레거시에서 하위 도메인들을 식별한다.
• 스파게티 코드안에 도메인 지식이 많이 숨겨져있고, 이때는 도메인 전문가도 없는 상황.
• 보통은 일반이나 지원 도메인(회원 기능등..)부터 분리한다. (핵심은 분리하기 어렵다.)
• DDD로 고도화 > 이때 제대로된 컨텍스트맵이 나오기 시작한다.
• 전술적 패턴선택, 핵심 컨텍스트를 뜯어낸다.(상황별로 여러개일수있다)
• 상황에 따라 지원 도메인이 핵심 도메인으로 승격되기도 한다.

결론, 세상의 모든것은 변한다. 수시로 변하는 비즈니스 상황을 맞춰가며 소프트웨어 개선이 지속되어야한다.

요약

• DDD는 일종의 접근법이자 철학이다.
• DDD에선 전략적 설계가 중요하다.
• 커뮤니케이션을 기반으로 지식탐구하고, 지식을 정제하자!
• 언제어디서나 유비쿼터스 언어로 설계하자.(긴밀하게 커뮤니케이션하자)