Background
Legacy Server
- Monolithic
- 기술 부채
- 유지보수의 어려움
- 기능의 고착화
이러한 어려움들을 도메인을 중심으로 개선해보자.
Domain Driven Design?
각각의 기능적인 문제에 영역들을 정의하는 도메인과 그 도메인을
사용하는 비즈니스 로직을 중심으로 설계를 하는 것을 말한다.
- 도메인의 모델과 로직에 집중
- Ubiquitous Language, 보편적 언어 사용
- Software Entity와 Domain간 개념의 일치
Why DDD?
DDD는 테스트 중심의 TDD 혹은 행위 중심의 BDD와 무슨 차이가 있을까
이미 검증된 플로우가 존재하고, 한 번에 갈아엎는 빅뱅 방식 대신 필요한 기능 등을 조금씩 구별하고 그것에 대해 필터링하여 개선하고 점진적인 향상을 만족시키는 것 그리고 레거시와 신규 서버를 동시 가동하기에 적합한 방법은 DDD가 될 수 있다.
DDD 적용에 필요한 것들
- Bounded Context
- Context Map
- Aggregate
1. Bounded Context
Bounded Context는 도메인 주도 설계(DDD)의 핵심 개념 중 하나로, 큰 도메인을 여러 개의 하위 도메인으로 나누어 관리하는 방법이다. 이는 복잡한 도메인을 이해하기 쉽게 쪼개는 것과 관련이 있다. 각각의 Bounded Context는 자신만의 독립적인 모델을 가지고 있으며, 다른 Bounded Context와는 독립적으로 동작할 수 있다.
- 주요 개념:
- 각 Bounded Context는 특정 비즈니스 영역 또는 하위 도메인을 설명하는 모델이다.
- 서로 다른 Bounded Context 간에는 모델이 다를 수 있으며, 이를 통해 복잡성을 낮출 수 있다.
- Bounded Context는 시스템을 보다 명확하게 이해할 수 있도록 경계를 설정하며, 팀 간의 책임을 명확히 나누는 데 도움을 준다.
- 예시: 예를 들어, 전자 상거래 시스템에서 "주문 관리"와 "재고 관리"는 서로 다른 Bounded Context로 나눌 수 있다. 각 Bounded Context는 고유한 모델과 로직을 가지며, 상호 작용할 때는 명확하게 정의된 인터페이스나 계약을 통해 통신한다.
2. Context Map
Context Map은 여러 Bounded Context 간의 관계와 상호 작용을 시각적으로 표현한 지도이다. 이것은 조직의 다양한 팀들이 작업하는 Bounded Context들이 서로 어떻게 연결되고 통합되는지를 명확히 이해하는 데 도움을 준다.
- 주요 개념:
- Context Map은 각 Bounded Context 간의 경계뿐만 아니라 그들 간의 관계도 명확히 정의한다.
- 이 지도는 서로 다른 팀들이 공유하는 모델을 설명하거나, 서로 독립적인 모델들이 어떻게 상호 작용하는지를 보여준다.
- Context Map은 다양한 패턴(예: Shared Kernel, Customer-Supplier, Anti-Corruption Layer 등)을 사용해 Bounded Context 간의 통합 방식을 표현한다.
- 용도: Context Map을 통해 개발자와 비즈니스 이해관계자가 시스템의 전반적인 아키텍처를 이해하고, 각 Bounded Context 간의 상호 의존성을 명확히 할 수 있다. 이를 통해 통합 문제를 사전에 예방하고, 각 팀이 독립적으로 개발을 진행할 수 있는 기반을 제공한다.
3. Aggregate
Aggregate는 DDD에서 사용하는 데이터 모델링 패턴으로, 특정한 논리적 경계를 가지는 객체 집합을 뜻한다. 이 객체들은 서로 연관성이 있으며, 하나의 단위로 취급된다. Aggregate는 단일 트랜잭션 내에서 일관성을 유지하는 중요한 단위이다.
- 주요 개념:
- Aggregate는 하나 이상의 객체들로 구성되며, 이 중 하나가 Aggregate Root라고 불리는 대표 객체가 된다.
- Aggregate Root는 외부에서 접근할 수 있는 유일한 진입점으로, 외부 시스템이나 다른 Aggregate는 오직 Aggregate Root를 통해서만 해당 Aggregate와 상호작용할 수 있다.
- Aggregate는 내부 일관성을 보장하는 단위로, 데이터 일관성을 유지하는 데 중요한 역할을 한다.
- 예시: 예를 들어, "주문" Aggregate는 주문, 주문 항목, 결제 정보 등의 객체들로 구성될 수 있다 이 중 "주문" 객체가 Aggregate Root가 되며, 외부 시스템이 이 Aggregate와 상호작용할 때는 항상 "주문" 객체를 통해서만 이루어진다. Aggregate 내부의 다른 객체들은 외부에서 직접적으로 접근할 수 없다.
요약
- Bounded Context: 도메인을 논리적으로 구분하여 각 하위 도메인별로 독립적인 모델을 정의하는 경계이다.
- Context Map: 여러 Bounded Context 간의 상호 관계와 의존성을 시각적으로 표현한 지도이다.
- Aggregate: 객체들의 일관된 집합으로, 하나의 단위로서 트랜잭션 및 데이터 일관성을 유지하며 Aggregate Root를 통해 외부와 상호작용한다.
Architecture
DDD의 대표적인 아키텍처는 이렇게 3가지가 있다.
Layered Architecture
- User Interface
- Application
- Domain
- Infrastructure
Clean Architecture
- External Interface
- Interface Adapter
- Use Case
- Entity
Hexagonal Architecture
There is No Silver Bullet
Cons
- MSA에서 오는 단점
- Architecture 구현에서 생성되는 많은 코드
- 각 도메인에 대한 높은 이해도가 필요
Pros
- 보편적인 언어 사용에 따른 빠른 커뮤니케이션
- 도메인간 관계가 복잡한 경우 큰 틀에서 정리가 가능
- 도메인의 분리에 따른 유지보수에 대한 편의성
- 새로운 기능 및 요구 사항에 대한 유연성
- Encapsulation
- Loose coupling, High cohesion
- Domain Logic 분리로 Business Logic에 집중
- 코드 가독성
'Architecture' 카테고리의 다른 글
| Spring Boot 디렉터리 구성 파헤치기 (0) | 2024.08.28 |
|---|
