DDD(Domain Driven Design)
DDD란
도메인 주도 설계(DDD)는 도메인과 도메인 로직(비즈니스 로직)을 중심으로 시스템을 설계하는 방법론입니다. DDD는 비즈니스의 핵심 개념과 규칙을 코드에 반영하여 일관성 있고 유지보수 가능한 구조를 만드는 것을 목표로 합니다.
이번 신규 개발 프로젝트에서는 기존의 TDD 기반 설계 방식도 고려했으나, 현재 기획서를 기준으로 명확한 테스트 사항들이 충분히 정해지지 않은 상황입니다. 따라서, 복잡한 비즈니스 로직을 유연하게 다룰 수 있는 DDD를 기반으로 시스템을 설계하고, 개별적인 테스트가 필요한 부분에서는 TDD를 병행하여 도입하기로 결정했습니다.
프론트엔드 관점에서 DDD를 적용할 시 장점
-
비즈니스 로직 중심의 코드 구조
우리 서비스를 기준으로 회원, 메뉴, 주문, 결제 등과 같이 도메인을 정의한다고 가정할 때, 프론트엔드에서 도메인 단위로 코드를 모듈화하여 관리할 수 있어 코드 일관성이 높아집니다. 이를 통해 복잡한 비즈니스 로직도 명확하게 정의할 수 있어 가독성도 높아집니다.
-
모듈 간 응집도 증가 및 결합도 감소
비즈니스 로직이 변경될 경우, 해당 도메인 내에서만 코드 수정이 이루어지며 다른 도메인에 미치는 영향을 최소화할 수 있습니다. 각 도메인이 독립적이므로 코드의 유지보수가 쉬워지고, 기능 추가나 변경도 유연하게 관리할 수 있습니다.
-
테스트 용이성
DDD를 통해 도메인 단위로 코드가 분리되어 있기 때문에 각 도메인에서 개별적인 테스트가 필요한 경우 테스트 코드 작성이 용이해집니다. 특정 도메인의 로직만 검증할 수 있어 테스트가 간결해질 수 있습니다.
-
상태 관리와 데이터 흐름의 일관성 유지
상태 관리 또한 도메인별로 나누어 관리하게 되므로, 비즈니스 흐름에 따라 각 도메인의 데이터 일관성을 유지할 수 있으며 유지보수도 쉬워지며 독립적인 상태 관리로 인해 코드의 가독성이 높아집니다.
프론트엔드 계층별 DDD 적용
도메인 계층: 비즈니스 규칙에 따라 유효성 검증 및 로직 정의
예: 주문 상태가 "PENDING"일 때만 "COMPLETED"로 변경 가능하도록 검증하는 completeOrder 함수.API 계층: 서버와의 통신을 담당
예: postAddItem 함수에서 서버에 장바구니 아이템 추가 요청을 전송.서비스 계층: API와 도메인 로직을 조정하고 상태 업데이트를 담당
예: placeOrder 함수에서 주문 생성 API 호출 후, 성공 시 주문 상태 업데이트.데이터 계층: 전역 상태 관리와 업데이트를 담당
예: Redux의 cartSlice에서 장바구니 상태를 저장하고 업데이트.도메인 이벤트 기반 아키텍처
시스템이 도메인 이벤트를 중심으로 동작하도록 설계된 아키텍처 스타일입니다. 이 아키텍처에서는 도메인 이벤트가 발생하면 다른 서비스나 모듈에서 이를 구독하여 상태 변화에 따른 후속 작업을 비동기적으로 수행할 수 있습니다.
예를 들어 도미노 서비스에서 주문 이벤트가 발생하면 결제가 이루어지고, 주문 접수 상태에 따라 피자가 준비됩니다. 준비가 완료되면 배달이 시작되는 식으로 상태 변화가 발생할 때마다 도메인 이벤트를 발행하고, 이를 구독하는 다른 서비스들이 후속 작업(예: UI 업데이트, 사용자 알림)을 처리하도록 설계할 수 있습니다.
이와 같은 예시로 주문 완료, 결제 실패와 같은 중요한 상태 변화를 이벤트로 도출하여 상태 관리와 연결할 수 있고, 이를 통해 주문 상태를 일관되게 업데이트하고 필요에 따라 실시간 알림을 제공하는 방식으로 사용자 경험을 개선할 수 있습니다.
