MSA 설계, DDD(Domain Driven Design), Event Storming

 

 

 

 

 

DDD : 마이크로서비스의 설계 방법론

 

 

 

1. Domain이란?

1) 사전적의미는 '영역', '집합'입니다.

2) DDD에서 말하는 Domain은 비즈니스 Domain입니다.

3) 비즈니스 Domain은 유사한 업무의 집합입니다.(MPRS - 마케팅, 구매, 연구, 영업)

4) 어플리케이션은 비즈니스 Domain별로 나누어 설계 및 개발될 수 있습니다.

 

2. DDD란? Domain Driven Design

• 실제 코드로 구현 가능한 현실성 있는 도메인 모델 분석과 그것을 추상화하는 설계.
• 도메인 모델의 적용 범위를 구현까지 확장하여 도메인 지식을 구현 코드에 반영합니다.

• 도메인과 일치하도록 소프트웨어를 모델링하는 것.

1) 비즈니스 Domain별로 나누어 설계하는 방식입니다. 

   기존의 어플리케이션 설계가 비즈니스 Domain에 대한 이해가 부족한 상태에서 설계 및 개발되었다는 반성에서 출발하였습니다. DDD에서는 기존의 현업에서 IT로의 일방향 소통구조를 탈피하여 현업과 IT의 쌍방향 커뮤니케이션을 매우 중요하게 생각합니다.

2) DDD의 핵심 목표는 "Loosly coupling", "High cohesion"입니다.
  (어플리케이션 또는 그 안의 모듈 간의 의존성은 최소화하고, 응집성은 최대화)

3) DDD는 Strategic Design과 Tactical Design으로 나눌 수 있습니다. Strategic Design은 개념 설계이고 Tactical Design은 프로그래밍하기 위한 구체적 설계라고 할 수 있습니다.

 

Strategic Design

• Business Domain의 상황(Context: 대상사용자, 상황)에 맞게 설계하자는 컨셉입니다.
   (예 : 선물구매라는 도메인을 설계할때 대상이 애인, 부모, 자식인지에 따라 달라져야 함)
• 전략적 설계를 위해 Business Domain의 상황(Context)을 Event storming으로 공유하고, 비즈니스 목적별로 서비스들을 그룹핑합니다.

 

Tactical Design

• 개발을 위한 구체적인 설계도입니다.

• Model Driven Design
  Strategic Design에서 설계한 Domain Model을 중심으로 설계하는 것을 말합니다.

• Lyaerd Architecture

  Tatical Design시 목적별 계층으로 나누어 설계하는것을 의미합니다.
  추천하는 Layer는 Presentation, Service, Domain, Data Layer가 있습니다.

 

---

 

Event storming

• 비즈니스 도메인 내에서 일어나는것들을 찾아 Bounded Context를 식별하는 방법론

• 알베르토 브란돌리니(Alberto Brandolini)가 제안한 워크샵으로 복잡한 비즈니스 도메인을 빠르게 탐색하고 학습하기 위한 방법입니다.
• 관련된 모든 도메인 전문가와 개발자를 함께 참여시켜서 비즈니스 지식을 모두가 이해할 수 있게 풀어 놓습니다.
• 이해하기 어려운 데이터베이스 및 코드를 이용하지 않고 모든 사람을 동일한 수준으로 만드는 시각적 접근방법입니다.
• Domain Driven Design을 잘 몰라도 거의 유사한 결과물을 얻을 수 있습니다.

 

 

 

1. Domain Event 정의 : 비즈니스 도메인내에 발생하는 모든 이벤트를 과거 시제 및 수동태를 사용하여 작성 - 오렌지색

• 시간은 왼쪽에서 오른쪽 방향이고

동시에 이루어지는 것은 아래에 붙입니다.

 

 

 

 

2. 핫 스폿 - 자주색

• 2단계에서 생긴 질문들을 붙입니다.
• 당장 토론하지 않습니다. 나중에 문제가 해결되면 제거합니다.

 

 

 

 

3. 액터와 외부 시스템

액터 – 노란색
• 액터는 사용자, 조직, 이해관계자 등 시스템과 상호작용하는 주체입니다.
• 액터는 사용자 UI를 통해 정보를 얻고 시스템에 결정을 내립니다.
• 단순한 ’사용자’ 또는 ‘고객’보다 구체적인 페르소나를 설정하는 것이 좋습니다.

 

외부 시스템 – 분홍색
• 외부 시스템은 Legacy 시스템 또는 SaaS 서비스 등 시스템의 책임을 전가할 수 있는 모든 대상을 의미합니다.

 

 

 

 

4. 커맨드(Command), 정책(Policy), 리드 모델(Read model)

커맨드(Command) - 파란색

• 시스템에서 일어나는 일
• 도메인 이벤트가 발생하는 원인
• 액터가 어떤 결정을 내려서 시스템에 요청하는 것을 커맨드(Command)라고 합니다.
• 액터가 외부 시스템에 요청하는 것도 커맨드(Command)로 도출합니다.
• 도메인 이벤트는 커맨드에 의해 발생합니다. 따라서 어떤 이벤트를 발생하게 한 커맨드가 무엇인지 찾아보는
방식으로 커맨드를 도출할 수 있습니다.

 

정책(Policy) - 연보라색
• 정책(Policy)는 어떤 이벤트에 이어서 곧바로 발생해야 하는 업무 규칙을 의미합니다.
• 주로 ‘~할 때마다’라는 단어로 시작합니다.
• 정책은 자동화된 소프트웨어에 의한 처리로 해석할 수도 있습니다.
     • 예) 새 사용자가 가입할 때마다 사용자에게 이메일을 전송한다.
• 정책은 주로 이벤트와 커맨드 사이에 위치합니다.

 

리드 모델 (Read model) – 연두색

• 결정을 내리는데 필요한 정보
• 리드 모델(Read model)은 도메인 이벤트의 결과를 제공하여 액터가 커맨드를 생성하도록 돕는 역할을
합니다.
• 액터가 어떤 결정을 내리는데 추가적인 데이터가 필요하다면 리드 모델을 통해서 제공되어야 합니다.
• 리드 모델은 주로 이벤트와 액터 사이에 위치합니다.

 

 

 

 

5. 애그리게잇 (Aggregates) – 노란색

• 커맨드를 처리하고 이벤트를 발생시키는 ”어떤 것”을 애그리게잇(Aggregates)이라고 합니다.
• 애그리게잇은 커맨드와 이벤트 사이에 존재합니다.

• 커맨드와 이벤트 사이에 별도의 외부 시스템이 없다면 애그리게잇을 배치합니다.
• 애그리게잇의 이름을 지을 때 이벤트에 사용된 명사를 이용하면 좋습니다.

 

• 시스템이 기대하는 책임을 수행하며 일관성을 유지하는 단위.
• 일관성은 항상 참이어야 하는 속성을 유지함으로써 달성됩니다.

• 실제로 주어진 클래스들의 계약을 정의하는 방법이며 내부의 구현은 자유롭게할 수 있습니다. 일종의 캡슐이라고 볼 수 있습니다.(개발자가 아닌 사람에게 에그리게잇이라는 용어를 강요해서는 안 됩니다. '이벤트 규칙'과 같은 말로 바꿔쓸 수 있습니다.)

 

 

 

 

6. 바운디드 컨텍스트 (Bounded Context)

• 도메인 모델을 더 명확하게 표현하기 위한 명시적인 경계

• 같은 맥락(Context)을 가지는 애그리게잇(Aggregates)들을 묶어서 바운디드 컨텍스트(Bounded Contexts)를 도출합니다.

• Bounded Context는 Biz Domain의 사용자, 프로세스, 정책/규정 등을 고유한 비즈니스 목적별로 그룹핑한 것입니다.  사용자, 프로세스, 정책/규정들을 그 Biz Domain의 Context라고 말할 수 있으므로 Bounded Context는 Domain안의 서비스를 경계 지은 Context의 집합이라고 할 수 있습니다.

 

 

 

 

 

 

 

 

 

 

참고 및 이미지 출처

 

https://happycloud-lee.tistory.com/94

 

https://rok93.tistory.com/170

 

https://www.youtube.com/watch?v=hUcpv5fdCIk&ab_channel=OpenUP-%EC%98%A4%ED%94%88%EC%97%85