DDD
DDD : Domain Driven Design (Development)
도메인 주도 설계로, 서비스의 "기능"을 기준으로 코드 구분을 하는 것이 아닌, 도메인이라는 비즈니스 영역을 기준으로 코드를 구분하는 것
코드의 역할과 책임이 명확해지고, 비즈니스 로직을 이해하고 관리하는 것이 한결 더 쉬워진다.
이벤트 스토밍
서비스와 관계 있는 모든 이해관계자들이 서로가 가지고 있는 생각을 공유하며 서비스에서 발생하는 이벤트를 중심(Event-First)으로 분석하는 기법
이벤트 스토밍을 통해 영역을 나눠서 서브 도메인을 만들고, 이는 곧 bounded context가 된다.
이것이 더 나아가서 MSA의 기반이 되기도 하는데 한 번 간단하게 알아보자.
- 서비스에서 어떤 주체가 어떤 행동을 취하는가?
- 그 행동의 결과로 어떤 이벤트가 발생하는가?
- 이벤트가 발생하면 시스템에서는 어떤 변화가 일어나는가?
- 이 이벤트가 다른 이벤트에 어떤 영향을 미치는가?
위 4가지 질문에 답을 얻어가며 서비스의 핵심 프로세스와 비즈니스 로직을 명확히 이해하고 모델링할 수 있을 것이다.
Domain Event
도메인에서 실제로 발생하는 결과를 뜻한다.
서비스에서 발생한 사실, 결과에 대해 Output을 표현하기 위해 사용한다.
Command
Command는 간단하게 비즈니스 로직, 하나의 트랜잭션이라고 생각하면 된다.
이벤트가 발생되기 전에 command가 붙는데, 말 그대로 사용자가 결제를 하겠다는 요청.
이 요청 자체가 Command에 속하게 되는 것이다.
Hotspot
수정하거나 궁금하거나 정해지지 않은 정책에 대해 표현하는 것. 다 정해지면 바로 떼면서 최종적으로는 붙어 있어서는 안 된다.
Actor
Command를 발생시키는 '주체'를 뜻한다.
ex) 고객이 상품을 '주문' -> 여기서는 주문자인 고객이 Actor
External System (외부 시스템)
Domain event를 호출하거나 관계가 있는 것을 표현할 때 사용한다.
ex) 결제 요청을 처리하기 위해서는 “결제 모듈”이라는 외부 시스템이 필요하며, 고객에게 알림을 전달하기 위해서는 “알림 모듈”이라는 외부 시스템이 필요할 것이다.
위 예제와 같이 서비스에 필요하지만, 외부 의존성을 가지는 시스템을 뜻한다.
Aggregate
상태가 변경되는 데이터 묶음으로 (연관되는 Entity와 값 객체의 묶음)
-> vo, enum, entity
ex) 고객이 자동차를 대여하는 요청을 하면, 자동차 대여점에서는 해당 요청을 처리하기 위해 필요한 자동차의 상세한 정보(차종, 연식, 주행거리 등)가 필요하게 된다.
Policy
event 조건에 따라 발생하는 추가적인(or 새로운) Command를 나타낸다.
비즈니스 로직들은 1개 행위는 1개의 결과만 발생할까? -> 아니다.
주문 요청 -> 주문 완료 -> 알림 생성 요청 -> 알림 발송 처럼 이벤트로 인해 발생하는 것들을 "정책"이라고 한다.
간단하게 개념을 알아보고 한 번 이번에 하는 프로젝트를 DDD를 활용해서 나타내볼까 한다.
