카테고리 없음

2024-05-09 [Kotlin+Spring DDD 전략적 설계(Strategic Design)]

Glen_check 2024. 5. 9. 17:38

Spring 으로 들어온 순간, 개념들이 어려워서 하나 하나 잘 짚고 넘어가야 할 것 같습니다.

금일 학습한 내용 중 도메인 주도 설계, DDD(Domain Driven Design)의 전략적 설계 개념이 앞으로 학습하는데 매우 중요할 것으로 보여 심화 학습을 진행해보려 합니다.

구글링해보며 여러 글들을 조합하고, 강의 자료도 참고하고, 나의 주관도 들어가 있어

혹시나 틀리거나 사장된 개념들이 있다면 댓글 대 환 영 입니다..

 

DDD(Domain Driven Design)에 기반한 기획

DDD는 실제 우리가 해결하고자 하는 분야(Domain)의 핵심 문제와 비즈니스 요구사항을 이해하고, 이를 소프트웨어 모델에 명확히 반영하는 것을 최우선으로 한 소프트웨어 개발 방법론 입니다.

때문에 DDD에는 요구사항을 명확하게 이해하고, 정의하는 부분까지 포함되어 있습니다.

초기 제품 개발 시 백엔드 개발자의 소통 주체는 주로 기획자이기 때문에 기획 과정을 잘 숙지하고 있다면, 기획자와의 소통이 원활해지고, 더 나아가 소프트웨어를 설계하는데에도 많은 도움이 될 수 있습니다.

 

여기서 Domain이란?

  • 사전적 의미는 '영역', '집합'으로, DDD에서 말하는 Domain은 비즈니스 Domain입니다.
  • 비즈니스 Domain은 유사한 업무의 집합입니다.(MPRS-마케팅,구매,연구,영업)
  • 여기서 Domain은 해결하고자 하는 분야를 의미하고 애플리케이션은 비즈니스 Domain 별 나누어 설계 및 개발 될 수 있습니다.

 

Domain 정의를 알았으니, DDD 를 조금 더 깊게, 특징을 살펴보자!

  • 도메인 그 자체와 도메인 로직에 초점을 맞춰, 일반적으로 많이 사용하는 *데이터 중심의 접근법을 탈피해서 순수한 도메인의 모델과 로직에 집중하는 것을 의미합니다.
  • 보편적인(ubiquitous) 언어의 사용이다. 도메인 전문가와 소프트웨어 개발자 간의 커뮤니케이션 문제를 없애고, 상호가 이해할 수 있고 모든 문서와 코드에 이르기까지 동일한 표현과 단어로 구성된 단일화된 언어체계를 구축해나가는 과정을 말합니다. 이로서 분석 작업과 설계 그리고 구현에 이르기까지 통일된 방식으로 커뮤니케이션이 가능해집니다.
  • 소프트웨어 Entity와 Domain Concept을 가능한 가장 가까이 일치시키는 것입니다. 분석 모델과 설계가 다르고 그것과 코드가 다른 구조가 아니라 도메인 모델부터 코드까지 항상 함께 움직이는 구조의 모델을 지향하는 것이 DDD의 핵심원리입니다.

데이터 주도 설계는 뭔데 ?

데이터 주도 설계란, 객체가 가져야 할 데이터에 초점을 두고 설계를 하는 방식을 일컫는다. 데이터 주도 설계 에서는 객체 자신이 포함하고 있는 데이터를 조작하는 데 필요한 행동을 정의합니다.

데이터 주도 설계 시 협력에 고민을 하지 않았기 때문에 과도한 접근자와 수정자가 탄생하게 된다. 이는 후에 객체가 어떤 곳에 사용될지 알 수 없기 때문에 최대한 많은 접근자와 수정자를 만들게 된 것 입니다.

결과적으로 데이터 중심 설계는 외부에 대부분의 구현이 노출되기 때문에 캡슐화의 원칙을 위반하게 되며,

내부 구현이 퍼블릭 인터페이스에 노출되며 이 때문에 다른 객체들과 강하게 결합되게 됩니다. 이로 인해 객체의 내부 구현이 변경될 때 이 인터페이스에 의존하는 모든 객체들이 함께 변경되므로 높은 결합도를 유지하게 됩니다.

 

DDD 정의 및 설계 과정

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

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

 

- DDD의 핵심 목표는 "Loosly coupling", "High cohesion"입니다.

(애플리케이션 또는 그 안의 모듈간의 의존성은 최소화하고, 응집성은 최대화)

 

- DDD는 전략적 설계(Strategic Design)와 전술적 설계(Tactical Design)라는 두 가지 주요 과정으로 나누어집니다.

  • 전략적 설계(Strategic Design) : 개념을 잘 정의하고 설계하는데 중점을 둡니다. 도메인을 서로 다른 영역으로 나누고, 각 영역(Context)에서 일관된 용어와 모델을 사용하여 각 영역과 관련해 팀원과 소통을 하고, 각 영역을 독립적으로 발전하고, 유지보수 하기 쉽게 만듭니다. 즉, 소프트웨어를 설계하기 전 요구사항에 대하여 명확이 정의하고, 개념적인 설계를 하는 과정이라고 볼 수 있습니다.

(애플리케이션을 통해 해결하고자 하는 문제들을 각각 다른 영역으로 나누고, 각 영역을 독립적인 문제로 정의하여 각 영역 관련하여 팀원과 소통하고 구축하며 설계해 나가는 것, 독립적으로 관리하기 때문에 유지보수 하기가 편하다.)

 

  • 전술적 설계(Tactical Design) : 각 영역(Context, Bounded Context) 도메인 모델을 만들고 구현하는 방법에 중점을 둡니다. 즉, 애플리케이션을 개발하기 위한 구체적인 설계 과정이라고 보시면 됩니다.

금일은 전략적 설계에 중점을 두어 학습할 예정입니다.

 

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

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

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

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

 

Design 과정 - Event Storming

  1. 각 요소 별로 다른 색의 포스트잇을 설정합니다. 여기서 요소는 위에서 정의된 Actor, Domain Event, Command, Policy, External System, Hotspot, Aggregate입니다.
  2. Actor를 정의합니다.
  3. Domain Event를 모두 나열합니다.
    • Event의 순서를 고려하여 나열하면 좋습니다.
    • Event를 정의하는 중간에 필요할 시, Policy와 Hospot을 정의합니다.
  4. Event 앞에 Command를 붙입니다.
  5. Event 뒤에 External System이 필요할 시 표기합니다.
  6. Command앞에 Actor를 설정합니다.
  7. Event들을 그룹핑하여 Domain Model 및 Aggregate를 정의합니다.
  8. 필요할 시, Bounded Context를 정의합니다.
  9. Model의 Data(Model이 담고 있는 정보)에 대해 정의합니다.

Event Storming 모두 다 중요하지만, 과정 중 Domain Event 와 Event 앞 Command 를 잘 정의하는 것이 가장 중요하다 생각합니다.

해당 문제들을 명확하게, 구체적으로 정의하지 못하고 API로 넘어갈 경우 문제가 누락되거나 API 기초 설계에 문제가 될 수 있습니다.

 

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

 

DDD 핵심만 빠르게 이해하기

마이크로서비스의 설계 방법론인 DDD(Domain Driven Design)에 대해 제가 가진 지식과 그간의 경험을 기반으로 정리하였습니다. 이 글을 읽기 전에 먼저 일하는 방식 변화를 이끌고 있는 애자일, 마이

happycloud-lee.tistory.com

해당 URL을 많이 참고하여 작성했는데, Event Storming 부분을 이해하기 쉽게 작성하여 해당 링크를 남겨놓습니다 : )

참고하여 이해해보면 좋을 것 같습니다.