도메인 주도 설계(DDD)는 큰 규모의 비즈니스를 각 도메인 별로 나누어 설계하는 방법론입니다.
예를 들어 이커머스 서비스의 경우 다음과 같이 도메인을 나눌 수 있습니다:
- 결제
- 주문
- 배송
- 고객관리
- 인증
이렇게 DDD는 큰 규모의 서비스를 작은 비즈니스 단위로 쪼개서 각 도메인 간의 응집도를 높이고, 서로 다른 도메인끼리는 느슨한 의존도를 가지게 합니다.
- 비즈니스 요구사항에 맞춰 모델링하기 용이하다: 각 도메인별로 비즈니스 로직을 명확하게 구현할 수 있습니다.
- 유지보수에 용이하다: 각 도메인끼리는 느슨한 의존도를 가지고, 도메인 내에서는 높은 응집도를 가지기 때문에 새로운 비즈니스를 추가하거나 제거하는 데 용이합니다.
- 도메인 간 결합도가 낮아 확장성이 좋다: 시스템을 확장하거나 변경할 때 다른 도메인에 미치는 영향을 최소화할 수 있습니다.
- 유비쿼터스 언어를 사용한다: 개발자만 이해 가능한 용어를 사용한다면 다른 파트의 동료나 도메인 지식이 부족한 개발자가 신규로 투입되었을 때 이해에 어려움을 겪을 수 있습니다.
- 충분한 고려 필요: 도메인 기반 설계가 무조건 만능은 아니기 때문에 각 프로젝트 성격에 맞는 구조를 고민해야 합니다.
이벤트 주도 아키텍처(EDA)는 시스템이 발생하는 사건(이벤트)에 반응하여 동작하는 구조를 의미합니다. 시스템 내의 다양한 구성 요소들이 이벤트를 발생시키고, 이를 처리하는 방식으로 동작합니다.
예를 들어 실시간 주식 거래 시스템의 경우 다음과 같은 이벤트가 발생할 수 있습니다:
- 주식 매수
- 주식 매도
- 가격 변경
이렇게 EDA는 이벤트가 발생하면 이를 이벤트 버스가 받아서 적절한 핸들러로 전달합니다. 매수 이벤트 핸들러는 주문을 처리하고, 매도 이벤트 핸들러는 판매를 처리하며, 가격 변경 이벤트 핸들러는 실시간으로 가격을 업데이트합니다.
- 확장성과 유연성 향상: 이벤트 기반으로 동작하기 때문에 시스템 확장이 용이합니다.
- 실시간 데이터 처리에 적합: 이벤트가 발생하자마자 처리할 수 있어 실시간 데이터 처리에 매우 유리합니다.
- 시스템의 독립적 구성 요소 관리: 각 이벤트 핸들러가 독립적으로 동작하기 때문에 시스템의 각 구성 요소를 별도로 관리할 수 있습니다.
- 디버깅이 어려울 수 있음: 이벤트가 비동기적으로 발생하고 처리되기 때문에, 디버깅이 어렵고 문제를 추적하기가 복잡할 수 있습니다.
- 데이터 일관성 유지가 복잡: 분산된 시스템에서 데이터의 일관성을 유지하기 어렵고, 추가적인 설계와 구현이 필요할 수 있습니다.
- 이벤트 관리 오버헤드 발생 가능: 이벤트 버스 및 스트리밍 플랫폼의 관리와 운영에 대한 오버헤드가 발생할 수 있습니다.
- 이벤트 흐름을 명확히 이해해야 한다: 시스템이 복잡해질수록 이벤트 간의 관계와 흐름을 명확히 이해하고 관리해야 합니다.