도메인 주도 설계 : DDD(Domain-Driven Design)
- 내용 추가 중입니다.
도메인
- 소프트웨어로 해결하고자 하는 문제 영역(비즈니스 영역)
- 소프트웨어를 개발할 때의 초점은 기술이 아니라 주로 비즈니스에 있어야함
도메인 주도 설계
- Eric Evans가 2004년에 출판한 Domain-Driven Design 책에서 소개한 설계 개념
- 실제 코드로 구현 가능한 현실성 있는 도메인 모델 분석과 그것을 추상화하는 설계
- 도메인 모델의 적용 범위를 구현까지 확장하여 도메인 지식을 구현 코드에 반영
도메인 모델
- Model
- 대상 도메인에 대한 추상적 표현으로 소프트웨어로 만들기 위해서 필요
- Domain Model
- 도메인 개념을 추상화 한 것
- 도메인을 이해하기 위한 개념 모델
- 개발을 위해서는 구현 모델 필요
- Domain Object
- 도메인 모델을 소프트웨어에서 동작할 수 있도록 나타낸 것
DDD 설계 도구 2가지
- Strategic Design : 개념 설계
- Tactical Design : 구체적 설계
Strategic Design
- 도메인 전문가와 소프트웨어 전문가 등 전체 프로젝트 팀과 함께 Bounded Context와 Ubiquitous Language, Context Map을 정의하는 것
- Event storming으로 공유하고, 비즈니스 목적별로 서비스들을 그룹핑
- Bounded Context
- Biz Domain의 사용자, 프로세스, 정책/규정 등을 고유한 비즈니스 목적별로 그룹핑한것
- 모델의 경계를 결정하며 한 개의 Bounded Context는 논리적으로 한 개의 모델을 가짐
- Ubiquitous Language
- 도메인 전문가와 개발자 사이의 의사소통의 어려움을 해결하고자 동일한 의미로 이해하는 언어
- 비즈니스 도메인에 따라 동음이의어가 많기 때문에 정확한 커뮤니케이션을 위해 공통언어를 정의하고 사용해야함
- Context Map
- Bounded Context간의 관계를 나타낸 도식화한 Diagram
Tactical Design
- 개발을 위한 구체적인 설계도
- 모델링 영역
- Model Driven Design
- Strategic Design에서 설계한 각 Sub Domain별 Domain Model(Context Map)을 중심으로 설계하는것
도메인 주도 설계의 장점
- 기술을 향상
- 유연성을 제공
- 인터페이스보다 도메인을 선호
- Ubiquitous Language를 통해 팀 간 커뮤니케이션 격차 감소
도메인 주도 설계의 단점
- 강력한 도메인 전문성을 갖춘 전문가가 필요
- 팀이 반복적인 관행을 따르도록 권장 필요
참고
'dev > 아키텍처' 카테고리의 다른 글
| 마이크로서비스 패턴(5) (0) | 2022.03.24 |
|---|---|
| 마이크로서비스 패턴(4) (0) | 2022.03.10 |
| 마이크로서비스 패턴(3) (0) | 2022.03.03 |
| 마이크로서비스 패턴(2) (0) | 2022.02.17 |
| 마이크로서비스 패턴(1) (0) | 2022.02.10 |
