이번에도 역시 너무나도 많이 들어보고 많이 볼 수 있었던 단어가 있어서 그 단어에 대해 알아보려 한다. 특별한 기술을 아니지만 이에 대한 이론을 알고 개념을 잘 알고 파악한 사람을 우대한 다는 채용공고를 정말 많이 볼 수 있었다.
바로 그 것은 DDD
이다.
DDD란 Domain Driven Design
의 약자로, 큰 규모의 비즈니스를 각 도메인 별로 나누어 설계하는 방법론이다.
이해하기 좋게 예를 들어 보자면, 만약 이커머스 서비스의 경우 다음과 같이 나눌 수 있다.
이처럼 DDD는 큰 규모의 서비스를 작은 비지니스 단위로 쪼개어 각 도메인 간의 응집도를 높이고 서로 다른 도메인끼리 느슨한 의존도를 가지게 된다. (출처)
이렇게만 보면 각각 독립적인 서비스를 연결한 구조인 MSA의 개념과 굉장히 유사해보인다.
✅ MSA를 탄생시킨 DDD
예상했던대로 MSA는 DDD로부터 왔다고 한다. DDD의 핵심 요소인 Loose Coupling(느슨한 결합)
과 High Cohesion(높은 응집)
은 MSA를 설계할 때 꼭 기억해야 할 설계 원칙이다.
DDD는 MSA의 서비스를 식별할 수 있는 도구를 제공할 뿐 서비스의 올바른 식별을 보장하지는 않는다. 즉, DDD를 사용한다고 MSA를 완벽하게 적용할 수 있는 것은 아니다.
✅ 도메인 그 자체와 도메인 로직에 초점을 맞춘다.
일반적으로 많이 사용하는 데이터 중심의 접근법을 탈피해서 순수한 도메인의 모델과 로직에 집중하는 것을 말한다.
✅ 소프트웨어 엔티티와 도메인 컨셉트를 가능한 가장 가까이 일치시키는 것
분석 모델과 설계가 다르고 그것과 코드가 다른 구조가 아니라 도메인 모델부터 코드까지 항상 함께 움직이는 구조의 모델을 지향하는 것이 DDD의 핵심원리이다.
✅ 보편적인(ubiquitous) 언어의 사용
유비쿼터스 언어
: 전략적 설계에서 비즈니스 전문가와 개발자가 비즈니스를 개념화하기 위해 사용하는 언어.
도메인에서 사용하는 용어를 코드에 반영하지 않으면 그 코드는 개발자에게 코드의 의미를 해석해야 하는 부담을 준다. 코드의 가독성을 높여서 코드를 분석하고 이해하는 시간을 절약, 용어가 정의 될 때마다 용어 사전에 이를 기록하고 명확하게 정의 함으로써 추후 또는 다른 사람들도 공통된 언어를 사용할 수 있도록 한다.
그러면 어플리케이션 모델을 발전시키고 새롭게 생기는 도메인 관련 이슈를 해결하기 위해 도메인 전문가와 끊임없이 협력할 수 있게 된다.
DDD는 전략적 설계(개념 설계)
와 전술적 설계(구체적 설계)
로 구분할 수 있다.
전략적 설계(개념 설계)
➡️ 설계(구체적 설계)
마이크로서비스를 식별하는 역할로, 복잡한 도메인의 경계를 상황(context)에 맞게 명확히 정의하는 과정으로, 이벤트 스토밍을 통한 도메인 중심의 큰 방향성을 정하게 된다.
도메인 전문가 및 기술팀이 함께 모여 유비쿼터스 언어를 통해 도메인 지식을 공유 및 이해하고 이를 기준으로 개념과 경계를 식별해 바운디드 컨텍스트(bounded context)로 정의하고 경계의 관계를 컨텍스트 맵(context map)으로 정의한다.
마이크로서비스를 도출하기 위한 시스템 안의 이벤트를 이해하는 도메인 전문가와 개발자들의 브레인스토밍 활동
어떻게 하면 효과적인 설계를 하고, 어떻게하면 큰 도메인을 마이크로서비스로 분할하는 것을 쉽고 빠르게 할 수 있을까 등을 고민한다.
✅ 이벤트 스토밍 Flow
1️⃣ 도메인 이벤트 작성
도메인 이벤트란
시간흐름에 따른 시스템의 동작을 의미한다. 이벤트들의 발생 순서를 고려하여 배치하여 하며, 작성할 때는 명사, 과거시제로 기록한다.
사용자가 이커머스 사이트에 접속후 물건을 구매하기까지의 과정을 도메이 이벤트화(Orange
)
2️⃣ 외부 시스템 작성
이벤트 발생시 부가적으로 호출되거나 관련되어지는 레거시 시스템
또는 외부시스템
을 명사형태로 명시한다.
결제 이벤트
에 따른 외부결제시스템, 알림 시스템이 있을 수 있으며, 배송 이벤트
에 따른 택배배송 시스템이 있을 수 있다.(Pink
)3️⃣ Command 작성
이벤트를 발생시키는 커맨드를 동사 형태로 작성한다. 이는 개발자 입장에서 구현하게 되는 API가 된다.
Blue
)4️⃣ Hotspot 작성
궁금한사항이나, 좀 더 논의가 필요한 사항, 결정하기 힘든 사항에 대한 내용을 작성한다.
Purple
)5️⃣ Actor 작성
엑터는 사람이나 조직의 역할을 말하는 것으로, 비즈니스를 수행하는 구제적인 역할을 고려해서 명사형태로 작성한다.
연한 Yellow
)6️⃣ Aggregate
애그리거트는 이벤트가 상태를 변경하는 요소의 묶음으로, 가장 작으 도메인 모델의 모듈 단위이다. 커맨드와 도메인 이벤트가 영향을 주는 데이터 요소로, 커맨드와 도메인이벤트 사이에 상단에 겹쳐서 작성한다.
진한 Yellow
)7️⃣ Bounded Context 정의
Bounded Context는
액터, 애그리거트, 커맨드 등을 고려하여 목적별로 그룹핑한것을 말하며, Domain안의 서비스를 경계 지은 Context의 집합이라고 할 수 있다.
8️⃣ Context Mapping
호출 관계를 명확히 이해할 수 있도록 컨텍스트 다이어그램을 그린다. 이를 통해 바운디드 컨텍스트 간의 관계를 파악하고 동기적 호출방식, 비동기적 호출방식을 고려한 표현도 가능하다.
동기적(실선)
: 항상 일관된 데이터필요, 컨텍스트간 의존도가 높음비동기적(점선)
: 결과적 일관성으로 처리가능한 관계✅ Event Storming Convention
💡 좋은 이벤트 스토밍 예시들
👉 도메인 지식 탐구를 위반 이벤트 스토밍(Event Storming) 요약
👉 [MSA] 이벤트 스토밍(Event storming)
👉 이벤트 스토밍을 통한 마이크로서비스 도출
전략적 설계를 통해 식별된 마이크로서비스의 내부를 상세하게 설계하는 것으로, 비즈니스의 고유한 활동을 정확하게 모델링하는 설계 패턴과 방법을 의미한다. 그리고 도메인 모델 및 모듈 등을 정의한다.
✅ 마이크로서비스 내부 구조 설계
헥사고날 아키텍처는
도메인 영역과 외부 기술 영역을 완벽하게 분리하기 위해서 필요한 구조.
고유한 비지니스 개념을 표현하는 도메인 모델, UI, DB 등 기술을 분리하는 것.
이후에 빠르게 변화하는 기술의 변경과 대체를 쉽고 빠르게 수행.
✅ Domain Modeling
이론적으로 완성된 도메인을 기반으로, 소스코드로 구현하기 위한 세부사항을 정의하는 단계
✅ Layered Architecture
Domain Model에서 역할에 따라 모델을 Entity, Value Object, Service 등으로 분리했다면...
레이어별로 분리하면 User Interface
, Application
, Domain
, Infrastructure
로 구분할 수 있다. 이처럼 레이어를 분리해야만 다른 사람이 코드를 읽고 이해하기 쉽습니다.
User Interface는 사용자의 요청을 하위 레이어로 전달하는 역할
Application은 복잡한 비즈니스 로직을 처리하는 레이어.
Domain은 도메인에 대한 정보, 객체의 상태, 도메인의 비즈니스 로직을 제공하는 레이어
Infrastructure는 영속성을 구현하거나 외부와 통신하는 기능을 제공하는 레이어
각 레이어는 아래와 같이 하위 레이어를 의존합니다. User Interface는 모든 하위 레이어를 의존할 수 있고 반대로 Infrastructure는 다른 레이어를 의존하면 안된다
💡 자세히
👉 MSA 이론 정리(전술적설계)
👉 DDD Quickly (도메인 주도 설계, 전술적-전략적 설계)
👉 카카오헤어샵의 DDD
💡 Reference
👉 DDD와 MSA 기반으로 좋은 서비스 개발하기
👉 DDD(Domain-Driven-Design)
💡 좋은 참고영상
👉 [Backend] ㄷㄷㄷ: Domain Driven Design과 적용 사례공유 / if(kakao)dev2022
👉 도메인주도 개발 시작하기
좋은 글입니다 ~! 많이 배웠습니다