DDD 핵심만 빠르게 이해하기

마이크로서비스의 설계 방법론인 DDD(Domain Driven Design)에 대해 제가 가진 지식과 그간의 경험을 기반으로 정리하였습니다.

이 글을 읽기 전에 먼저 일하는 방식 변화를 이끌고 있는 애자일, 마이크로서비스, 데브옵스, 클라우드에 대해 

기본적인 이해를 하실것을 권장 합니다.

https://happycloud-lee.tistory.com/261?category=8322466

일하는 방식 변화 핵심만 빠르게 이해하기: 애자일, 마이크로서비스, 데브옵스, 클라우드

 

그럼 시작해 보겠습니다.

아래 글은 에릭 에반스(Eric Evans)의 '도메인기반디자인'을 번역한 글인듯 한데 직역하다 보니 의미가 잘 전달 안되는 부분이 있어 제 나름대로 조금 더 쉽게 풀어서 정리하였습니다.

참고: https://steemit.com/kr/@frontalnh/domain-driven-design

 

 

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은 프로그래밍하기 위한 구체적 설계라고 할 수 있습니다.

 

3. Strategic Design

1) Business Domain의 상황(Context: 대상사용자, 상황)에 맞게 설계하자는 컨셉입니다.
   (예: 선물구매라는 도메인을 설계할때 대상이 애인, 부모, 자식인지에 따라 달라져야 함)

2) 전략적 설계를 위해 Business Domain의 상황(Context)을 Event storming으로 공유하고, 비즈니스 목적별로 서비스들을 그룹핑합니다.

3) Bounded Context & Domain Model

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

  - Domain Model은 비즈니스 도메인의 서비스를 추상화한 설계도입니다. Domain을 Sub Domain으로 분해한것과 Bounded Context가 Domain Model입니다.

4) Bounded Context & Micro Service: 1개의 Bounded Context는 최소한 1개 이상의 Micro service로 구성됩니다.

5) Context Map: Bounded Context간의 관계를 나타낸 도식화한 Diagram입니다.

6) Ubiquitous Language

   - 현업, 개발자, 디자이너 등 참여자들이 동일한 의미로 이해하는 언어입니다.

   - 비즈니스 도메인에 따라 동음이의어가 많기 때문에 정확한 커뮤니케이션을 위해 공통언어를 정의하고 사용해야 합니다.

   - 하나의 도메인내에서는 어떤 단어나 문장이 동일한 의미로 소통됩니다. 예를 들어 '마우스'라는 단어는 '컴퓨터부속품생산'도메인내에서는 '컴퓨터 화면 안에서 커서를 옮기는 컴퓨터 부속품'으로 통용됩니다. '해충박멸서비스'도메인내에서는 '꼬리 달리고 털이 나있는 짐승'으로 이해됩니다.

 

7) Strategic Design의 결과물: Domain Model

  - Problem Space: Biz Domain 분할

    . Core Sub-Domain: 비즈니스 목적 달성을 위한 핵심 도메인으로 차별화를 위해 가장 많은 투자가 필요함

    . Supporting Sub-Domain: 핵심 도메인을 지원하는 도메인

    . Generic Subdomains:  공통 기능(메일, SSO 등) 도메인으로서 3rd Party제품을 구매하는것이 효율적임

     Domain 분해 예제: 온라인 음식 주문 업무

     주문, 주문중계, 음식점업무, 배달대행의 최상위 도메인을 정의하고 각 도메인을 서브도메인으로 분해함.

     서브도메인은 유사한 업무를 그룹핑한것입니다.

- Solution Space: Context Map 정의

- 관계의 종류  . Shared Kernel: 복수의 Bounded Context가 공통으로 사용하는 Bounded Context간의 관계  . Upstream-Downstream: Publisher(=Upstream)와 Subscriber(=Downstream) 관계 - Bounded Context의 특성 종류  . Open Host Service: 여러 종류의 Downstream Bounded Context를 고려하여 설계되는 Upstream Bounded Context  . Anti Corruption Layer: 다른 Bounded Context에서 받는 데이터를 본인에 맞게 구조, Type, 통신프로토콜 등을 변환해 주는 모듈계층을 가지는 Bounded Context. 보통 Downstream Bounded Context가 ACL을 가짐.

 

 

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

각 Step을 쉽게 이해하기 위해 위 온라인음식주문시스템의 '주문'도메인의 '주문'서브도메인을 예제로 제공하겠습니다.

(색깔은 조금 다를 수 있으니 감안하여 보시기 바랍니다.)

 

Step1. Domain Event 정의: 비즈니스 도메인내에 발생하는 모든 이벤트를 과거형으로 기술 - "오렌지색"

- 이벤트는 Actor가 Action을 해서 발생한 결과입니다. 보통 문장은 "XXX가 되었다."형태가 됩니다. - 각자 생각나는 Event를 적고 바로 순서없이 붙입니다. 더 이상 생각이 안 날때까지 붙입니다. 서로 상의하지 않습니다. - 서로 상이하면서 중복된것을 없애거나 합칩니다.  - 이벤트가 발생하는 시간 순서대로 붙입니다. 동시 수행되는 이벤트는 수직으로 붙입니다. - 이슈/개선사항/관심/재논의 사항이 있으면 "빨간색" 포스트잇으로 이벤트 옆에 붙입니다. * 주의: 비즈니스 용어로 무슨 일이 발생했는지를 적는것이지, 시스템 내에서 발생되는것을 찾는게 아닙니다. * TIP: 왼쪽과 오른쪽에 공간 여유를 두고 붙이십시오.

 

Step2. Tell the story: 도출된 이벤트로 도메인의 업무 흐름을 이해하고 토론하여 보완

- 도메인 전문가가 도출된 이벤트를 갖고 업무 흐름을 설명합니다. - 상호 질문을 통해 도메인 이벤트를 추가하거나 조정합니다. - 이슈/개선사항/관심/재논의 사항이 있으면 "빨간색" 포스트잇으로 이벤트 옆에 붙입니다.

 

Step3. 프로세스로 그룹핑: 이벤트들을 프로세스로 그룹핑

 

- 동일한 비즈니스 주제(업무 프로세스)로 이벤트들을 그룹핑합니다. "보라색" 포스트잇에 프로세스명과 간략설명을 기술합니다. - 비즈니스적으로 중요한 핵심 프로세스에 집중합니다. 핵심 프로세스에 중요한 이벤트가 누락되지 않았는지 검토합니다.   지원 프로세스는 너무 자세하게 이벤트를 식별하지 않습니다. - 이슈/개선사항/관심/재논의 사항이 있으면 "빨간색" 포스트잇으로 이벤트 옆에 붙입니다.

 

Step4. Command 정의: 각 Domain Event를 발생시키는 명령을 현재형으로 정의하며 명령형(ex: 제품목록을 검색)으로 기술 - "파란색"

- 사용자의 행위가 Command가 됩니다. Command는 일반적으로 '무엇을 CRUD 요청한다." 또는 "무엇을 XX한다.'의 형태가 됩니다. (CURD란 Create Update Read Delete의 약자입니다.)   예) 자동이체계좌의 등록을 요청한다. 판매상품 목록의 조회를 요청한다. 고객의 이메일 변경을 요청한다. 관심상품을 선택한다. - 각 Event별로 그 Event를 발생시키는 Command가 무엇인지 생각하여 Event 왼쪽에 붙입니다. Command 하나에 1개 이상의 Event가 발생할 수 있습니다.  ※ 추가적인 Event가 생각나면 추가할 수 있습니다.

 

Step5. Trigger 정의: Command를 일으키는 Actor와 Event를 일으키는 External System와 Policy/Rule을 정의

- Command를 수행하는 Actor를 정의합니다. Actor를 Command의 왼쪽 하단에 겹쳐서 붙입니다. - "하늘색"   Actor는 사람이며, 구체적인 사용자 유형을 적는것이 좋습니다. - Event 발생과 관련된 외부 시스템이 있다면 Event의 우측 상단에 겹쳐서 붙입니다. - "초록색"   Command의 요청을 받아 데이터만 제공해 주는 경우도 있고, 직접 무언가를 처리해서 결과를 리턴하는 외부시스템도 있습니다.   또한, 외부 시스템은 Command 없이 Event를 발생시킬 수도 있습니다.   (예: '푸시알림이 도착했다.'라는 이벤트는 '카카오톡'같은 외부시스템이 Command 없이 발생시키는 이벤트입니다.)    외부시스템이란 현재 시스템 밖에 있는 시스템을 의미합니다. 회사 내 시스템일 수도  있고, 회사 외부에 있는 시스템일 수도 있습니다. - 이벤트와 관련된 정책이나 규정이 있으면 Event 우측 하단에 붙입니다. - "보라색"   그 이벤트가 발생하기 위해 사전 체크할 정책/규정(예: 이름, 이메일은 필수 정보)이나 이벤트 발생 시에 정책/규정(예: 주민번호 뒷자리는 마스킹 처리)을 적습니다.   또한, 정책(Policy)이나 규정(Rule)은 Event를 발생시킬 수 있습니다. 보통 이러한 정책/규정은 시간과 관계가 있습니다.   예를 들어 "매월 말일에 1개월 내 만기가 도래하는 고객 리스트를 전 영업직원에게 메일로 통보한다."라는 Rule이 있다면 이 Rule도 "1개월 내 만기 도래 고객 리스트가 통보되었다"라는 이벤트를 일으키는 Trigger가 됩니다.

 

Step6. Aggregate 정의: Command 수행을 위해 CRUD해야 하는 데이터 객체 정의 - "노란색"

Aggregate는 아래와 같이 Entity와 VO의 집합입니다. 하지만 Event storming때 이렇게까지 도출하는것은 어려울 경우가 많습니다.

따라서, 이 단계에서는 Entity까지만 정의하고 다음 단계인 Bounded Context단계로 진행할것을 추천합니다.

Aggregate 이해하기 한 단위로 취급 가능한 경계 내부의 도메인 객체로서 한개의 루트엔터티와 기타엔터티+Value Object로 구성됩니다. 쉽게말해, Aggregate는 고유의 비즈니스 목적 수행을 위한 데이터 객체들의 집합입니다. 예를 들면 피자주문DOMAIN의 Aggregate에는 Order, Consumer, Restaurant가 있습니다.  Order Aggregate에는 Order, DeliveryInfo, PaymentInfo라는 Entity가 있고, Order Entity는 OrderLineItem(메뉴별 주문량)이라는 VO와 연결됩니다.  Order와 OrderLineItem은 1:N의 관계가 됩니다. [출처] 마이크로서비스패턴 (크리스리처드슨 지음) Aggregate 규칙: RPO - Root only-Aggregate Root만 참조: Aggregate내부의 entity나 VO를 접근할 때 직접하지 말고 Aggregate root를 통해서 해라 - Primary key-참조는 Primary key 사용: 다른 Aggregate를 참조할때 객체자체를 레퍼런스하지 말고 객체의 primary key로 참조해라. Order는 Consumer 객체 자체를 참조하지 않고, consumerId값으로 Consumer aggregate를 참조함. - One to One -한 개의 트랜잭션은 한 개의 Aggregate만 Writing 마지막 규칙은 동일한 서비스안의 RDBMS에서는 1:N이 될 수도 있습니다. 즉, 한개의 트랜잭션이 복수개의 Aggregate를 writing할 수 있습니다.

 

- Command를 수행해서 Event를 발생시키려면 어떤 데이터(정보)가 필요한지 각 Command와 Event 사이의 위에 적습니다. 색깔은 아무거나 상관없고, 동일한 색깔로 해주십시오.

 

- 어떤 데이터가 다른 데이터에 포함될 수 있으면 한 데이터로 묶습니다. 예를 들면 "배송지주소"는 "주문자정보"에 묶일 수 있고, "결재방식종류"는 "결제수단정보"에 묶일 수 있습니다. 색깔은 아무거나 해도 되며 통일해 주십시오.

또한 유사한 목적의 데이타들도 하나로 묶습니다.

이렇게 그룹핑된 데이터를 Entity라고 합니다.

 

Step 7. Bounded Context정의 - "분홍색"

- Entity, command, event, actor, Policy/Rule을 보면서 어떤 주제와 관련되었는지를 논의 합니다. - 바운디드컨텍스트는 사용자, 프로세스, 정책/규정 등을 고유한 비즈니스 목적별로 그룹핑한것입니다.   Entity, command, event, actor, Policy/Rule을 보면서 어떤 주제와 관련되었는지를 논의 합니다. 프로세스 그룹핑한것도 참조합니다.   - 그 주제별로 경계를 선으로 구분합니다. 처음에는 흐린색 펜으로 그리고 확정되면 검은색 마커팬으로 그립니다. - 그 주제명, 즉 Bounded Context의 명칭을 "분홍색" 포스트잇에 적어 붙입니다. * 이해를 돕기위해 필요하면 UI를 포스트잇에 그려 붙일수 있습니다.

 

Step 8. Context Map 작성

Bounded Context간의 관계를 도식화합니다.

관계의 종류 - Shared Kernel:    복수의 Bounded Context가 공통으로 사용하는 Bounded Context간의    관계 - Upstream-Downstream:    Publisher(=Upstream)와 Subscriber(=Downstream) 관계 Bounded Context의 특성 종류 - Open Host Service: 여러 종류의 Downstream Bounded Context를    고려하여 설계되는 Upstream Bounded Context - Anti Corruption Layer: 다른 Bounded Context에서 받는 데이터를   본인에 맞게 구조, Type, 통신프로토콜 등을 변환해 주는 모듈 계층을   가지는 Bounded Context

 

바운디드컨텍스트(B/C)간의 관계와 외부시스템(External System)이 어떤 B/C와 관계 되는지를 표현합니다.

쉽게 관계를 생각하는 TIP은 Bounded Context를 마이크로서비스라고 생각하는 것입니다.

아래 예제는 주문서비스가 음식서비스에 음식점과 메뉴 정보 요청을 하고, 주문서비스가 결제서비스에 결제를 요청하는 관계를 표현한 그림입니다.

 

마이크로서비스 설계에 대한 경험이 쌓이고 동기/비동기 차이를 이해하게 되면 Context Map에 동기/비동기 구분까지 표시해 봅니다.

동기 처리를 하는 경우는 실선을, 비동기 처리를 하는 경우는 점선을 사용합니다.

아래 예제는 음식B/C에서 음식점, 메뉴를 선택 완료하였다는 메시지가 오면, 주문B/C가 주문을 위한 어떤 처리를 한 후, 결제를 요청하고 주문을 완료하는 관계를 표현한 Context Map입니다.

 

 

PostIt색깔 정리: 색깔은 상황에 따라 변경해도 됩니다.

- 주황색(오렌지색): Event

- 파란색: Command

- 하늘색: Actor

- 초록색: External System

- 노란색: Aggregate

- 보라색: Policy/Rule

- 분홍색: Bounded Context 

* 분홍색 없으면 보라색으로 사용

---

 

4. Tatical Design

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

2) Model Driven Design

Strategic Design에서 설계한 각 Sub Domain별 Domain Model(Context Map)을 중심으로 설계하는것을 말합니다.

 

3) Layered Architecture

  - Tatical Design시 목적별 계층으로 나누어 설계하는것을 의미합니다.

  - 추천하는 Layer는 Presentation, Service, Domain, Data Layer가 있습니다.  

아래는 Martin Fowler가 얘기하는 Layer구조입니다. 

그림출처: https://martinfowler.com/bliki/PresentationDomainDataLayering.html

    . Presentation Layer: UI Layer

    . Service Layer: Domain Layer와 Data Layer의 class들간의 제어(Control) 또는 연결(Interface)을 합니다. Biz logic을 이 layer에 구현하지 않습니다.

    . Domain Layer: Domain Object별로 Business Logic처리를 담당하는 Layer

    . Data Layer: Database와의 CRUD처리 Layer

Springboot에서는 각 Layer의 목적에 맞게 3가지 어노테이션을 지원합니다. 

- Presentation Layer => @Controller, @RestController

- Service Layer, Domain Layer => @Service

- Data Layer => @Repository

참고) Domain Layer에 @Component를 사용하는 사람도 있는데, @Component는 @Controller, @Service, @Repository의 상위 개념이므로 맞지는 않는것 같습니다. 

Domain Model vs Transaction script 왜 Service layer와 Domain layer를 나눠야 할까요 ? Domain Model에서는 Service Layer의 class들은 흐름제어만 하고 Domain layer의 class들이 비즈니스 로직을 처리합니다. Transaction script에서는 Service(아래에선 Domain으로 표시되었으나 Service가 더 맞음) class들이 흐름제어와 비즈니스로직을 모두 합니다. [출처] 어플리케이션 아키텍처와 객체지향(1:01:34초) Service Layer와 Domain Model Layer를 나누는 이유는 새로운 비즈니스 요구에 대응할 때 기존 소스에 영향도를 최소화하고, Domain layer의 재활용성을 극대화하기 위함입니다.  Bounded Context '영화'의 결재금액요청 시 할인금액을 결정하는 서비스를 예로 들어 이해해 봅시다. 트랜잭션스크립트 패턴일때는 '할인금액처리 class'가 할인정책class를 통해 정책데이터를 읽은 후 할인금액을 계산해야 합니다. 도메인모델 패턴일때는 '할인금액처리 class'는 요청만 하고 '할인로직class'가 할인정책을 읽어 적절한 서브class에 할인금액 계산을 요청합니다. 만약 정액할인(예: 10회 관람자는 1000원 할인) 또는 비율할인(예: 조조관람은 10% 할인) 정책만 있었는데 복합할인정책(정액+비율할인)을 추가했다면 어떻게 해야 할까요 ? 트랜잭션스크립트의 '할인금액처리class'는 소스를 수정해야 합니다. 하지만 도메인모델 패턴에서는 '복합할인로직class'만 추가하면 됩니다.

 

  - 참조:

     - 객체지향적으로 개발하기: https://wckhg89.tistory.com/13

        (위 글은 Service Layer의 비즈니스로직을 Data layer로 옮기자는 주장입니다. Domain layer로 분리하는게 더 좋습니다. )

    . 어플리케이션 아키텍처와 객체지향: https://www.youtube.com/watch?v=26S4VFUWlJM

 

4) Entity & Value Object: 식별성과 가변성으로 구별

  - Entity는 각 record간에 구별이 필요한 객체이고, VO는 각 record간에 구별이 필요없는 객체입니다. 예를 들어 '지폐'라는 객체는 '일련번호'라는 고유ID로 구별되어야 하므로 Entity입니다. '금액'이라는 객체는 '액수'와 '통화'라는 속성이 중요하지 구별할 필요가 없으므로 VO입니다. '01' ID를 가지는 지폐 entity와 '02'ID를 가지는 지폐 entity는 '50000'이라는 액수와 '원'이라는 통화를 가지는 동일한 VO를 가질 수 있습니다. 

  - Entity는 가변적(Mutable)이고, VO는 불변성(Immutable)을 가집니다. 예를 들어 '01'ID를 가지는 지폐 enity의 '소유자'라는 속성은 변할 수 있습니다. 그러나 '50000원'이라는 VO의 '액수'와 '통화'는 한번 생성되면 소멸될때까지 변할 수 없습니다.

  - VO를 권고하는 이유는 속성 자체도 객체화하여 어플리케이션의 유연성을 높이자는 취지입니다. 따라서 속성이 또 다른 하위 속성들로 구성된다면 VO로 하라는 것입니다. 예를 들어 '사람' Entity의 '연락처'라는 속성이 있는데 '연락처'의 속성이 '핸드폰', '회사전화', '집전화'로 나눠 진다면 '연락처'VO를 만들라는 것입니다.

  - 개발 시 Entity의 프라퍼티는 string과 같은 기본형이 아닌 VO객체로 하는 것이 좋습니다. 그리고 VO class는 자체적으로 속성에 대한 type변환과 validation체크를 구현하는 것이 좋습니다.

  - VO vs MAP논쟁: VO의 장점은 속성의 type이나 validation rule같은것이 변경 되었을 때 유연하다는 것입니다. 단점은 잘못쓰면 복잡성이 증가되고, DB스키마 변경 시 관련된 VO도 수정해야 한다는 것입니다. 현실적으로 SQL에 많이 의존하거나(DAO사용), DB스키마의 변경이 빈번하게 예상된다면 VO class보다 구조체(Map)가 더 효율적일 수 있습니다.

물리적 설계관점에서 Aggregate, Entity, VO(Value Object) Aggregate는 논리적인 DB객체입니다. DB가 테이블을 갖듯 하위에 entity와 VO(Value Object)를 멤버로 갖습니다. entity는 논리적 테이블 객체라고 생각하면 되고 entity의 class형태의 속성이 VO입니다.

 

5) Aggregate & Factory

  - Aggregate는 Entity들을 대표하는 추상화된 객체입니다. 유연한 어플리케이션 개발을 위해 Entity간에 직접 커뮤니케이션하지 않고 Aggregate간에만 커뮤니케이션 하도록 설계 합니다. 위 Event storming에서 정의한 Aggregate가 Tactic설계 시 그대로 이용됩니다. 

  - Factory는 Aggregate의 생성 처리를 담당하는 객체입니다. 개발에 따라선 Entity의 생성을 담당할 수도 있습니다.

  - 위 영화예매 어플리케이션을 통해 이해하면...

     . Entity : 사용자, 영화, 영화예매, 영화상영, 할인정책, 할인규정은 식별되어야 하고 속성이 변할 수 있기 때문에 Entity가 됩니다.

     . VO: 더 구체적으로 설계하면 나오겠으나, 현재는 없습니다.

     . Aggregate: 사용자, 영화, 영화예매가 Aggregate가 됩니다. 영화Aggregate는 하위에 Aggregate root인 '영화'가 있고 영화 밑에 '영화상영', '할인정책', '할인규정' Entity를 가집니다. 

     . Factory: 영화Creator

     * 영화Aggregate가 없다면, 영화예매 entity는 영화, 할인정책, 할인규정 entity와 직접 통신해야하나, 영화Aggregate가 있으면 영화예매 aggregate는 영화Aggregate에 요청만 하면 됩니다.

     * '영화Creator' Factory가 없으면, 새 정책 추가 시 영화 Aggregator를 수정해야 함. 영화Creator Factory가 있으면, 새 정책 추가 시 새 정책에 맞는 영화Aggregator를 하나 더 만들고 영화Creator Factory는 정책에 맞는 영화Aggregator를 생성하면 됨.

 

6) Repository:

  - Data access를 처리하는 객체입니다.

  - Aggregate, Entity를 위해 데이터 CRUD를 담당합니다.

  - 실제 구현시에는 ORM을 쓰는것이 가장 이상적입니다. 

 

7) Tatical Design객체 관계도

8) Tatical Design 결과물

  - Userstory: BC내 기능과 Test case를 사용자 중심으로 기술

<sample>

  - Sequence diagram: BC내 객체(Entity)간의 처리 순서를 기술

<sample>

  - Class diagram: Service layer, Domain Model layer의 class를 정의

<sample>

  - Data diagram: Data 구조 정의. ERD와 동일함.

<sample>

  - Storyboard(화면설계서)

<sample>

 

- API설계서 : Micro service의 API 명세서

 

- Message 설계서: 비동기 메시징 설계서. 마이크로서비스 간 통신 방법을 기술

- 마이크로서비스패턴 적용 설계서: 마이크로서비스의 최적 아키텍처 설계를 위한 다양한 패턴 적용 방법 기술

마이크로서비스 패턴에 대해 짧은 시간에 이해하고 실제 예제를 통해 명확히 이해하고 싶은 분들은 

아래 [마이크로서비스 패턴 쉽게 개발] 시리즈가 도움이 되실 겁니다.  

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

[마이크로서비스 패턴 쉽게 개발] WHY 마이크로서비스 패턴 ?

 

 

 

 

Tools

1) Sequence, Class, Data diagram은 아래 사이트에서 작성하여, Asset화 할 수 있습니다.

https://www.planttext.com/

각 Diagram 예제는 https://plantuml.com 에서 참조할 수 있습니다.

https://plantuml.com/sequence-diagram

https://plantuml.com/class-diagram

https://plantuml.com/ie-diagram

2) Storyboard는 아래 툴들을 이용하시면 편합니다.

카카오 오븐: https://ovenapp.io/

OvenApp.io

 

퍼블레싱

https://happycloud-lee.tistory.com/236?category=902419 

퍼블레싱 소개

 

JustInMind: www.justinmind.com/ 

Free prototyping tool for web & mobile apps - Justinmind

 

SUMMARY

• Domain이란 유사한 업무의 집합을 말한다. (마케팅, 구매, 연구, 영업 등)
• Domain Driven Design은 비즈니스 도메인별로 나누어 설계하는 방법론이다.
• 한 Domain 내에서는 Ubiquitous Language가 사용되어야 한다.  즉, 모두가 공통으로 이해하는 통일된 용어가 필요하다.
• Context란 도메인의 사용자, 프로세스, 정책 등을 의미한다. 고유의 비즈니스 목적별로 Context를 나눈것이 Bounded Context이다.
• DDD는 전략설계와 전술설계로 나뉜다.
• 전략설계의 산출물은 Domain Model이고 Domain 분해도와 Context Map으로 구성된다.
• Domain 분해도는 최상위 도메인을 서브도메인으로 나누고 각 서브도메인의 Type을 Core, Support, Generic으로 나눈 것이다.
• Context Map은 Bounded Context간의 관계를 도식화한것이다.
• Event Storming은 도메인에 대한 공통의 이해를 위해 도메인에서 일어나는것들을 찾는 방법이고 일련의 과정을 통해 Bounded Context를  식별한다.
• 각 Bounded Context를 Micro Service로 나눈 후 각 마이크로서비스별로 설계한다.
• 마이크로서비스는 Layered Architecture로 설계하는 것을 권장한다. Presentation, Service, Domain Model, Data Access
• 전술설계의 객체에는 Entity, VO(Value Object), Aggregate, Factory, Repository가 있다.  Entity- 구별필요, VO-구별X, Aggregate-Entity집합
• 전술설계의 결과물은 Userstory(주체가 사람인 요구사항명세서), Usercase diagram, Sequence Diagram, Class diagram, Data Model, Storyboard(화면설계서), API설계서와 같이 기존과 유사한 산출물과 메시지설계서, 마이크로서비스패턴 적용 설계서와 같은 마이크로서비스에 특화된 설계서가 있다.
• Design Thinking은 사용자에 대한 공감과 이해를 통해 사용자 경험을 향상시킬 아이디어를 찾는 방법론이다.  DDD시작 전에 아이디에이션을 위해 수행하면 좋으며, 그 결과를 DDD로 구체화 시킨다.