[마이크로서비스패턴] DDD에 대해 알아보자

DDD란?

Domain-Driven Design의 약자로 복잡한 비즈니스 로직을 개발하기 위해 OOD를 개선한 접근 방식이다.

도메인 내부에서 문제 해결이 가능한 형태로 모델링하는 기법으로 공용 언어를 정의한다.

DDD와 마이크로서비스 아키텍쳐를 함께 적용하기 위해 알아야할 것들이 있다.

 

공용 언어

공용 언어를 정의해 도메인 간 용어 혼동이 일어나지 않게 해야 한다.

하위 도메인

단일 통합 모델은 여러 도메인 간의 합의를 이끌어 내기 어렵다. DDD는 각 서비스가 자체 도메인 모델을 가지며 전체 도메인 모델 문제를 해결할 수 있다.

경계 컨텍스트(Bounded Context)

도메인 모델의 범위이다. 이러한 모델을 표현하며 모든 관련 책임자의 업무 이해를 높일 수 있다.

또한 설계와 개발이 따로 분리되어 존재했던 문제도 통합시켜야 한다.

각 컨텍스트 경계들은 응집성이 높고, 다른 컨텍스트 경계와의 결합도가 낮아야 한다.

 

DDD에 필요한 모델들

Entity: 영속적인 신원을 가진 객체이다.

VO: 값만을 가진 객체이다. 

Factory: 보통 정적 팩토리 메서드를 통해 객체 생성을 대신 한다.

Repositry: DB 접근 기술을 캡슐화한 객체

Service: 엔티티, 밸류에 속하지 않는 비즈니스 로직 구현 객체이다.

 

애그리거트 패턴!

기존의 문제: 비즈니스 객체의 경계가 불분명하다는 단점이 있어 MSA 아키텍쳐와 어울리지 않는다.

애그리거트는 한 단위의 취급 가능한 경계 내부의 도메인 객체들이다. 

하나의 루트 엔티티와 기타 엔티티 + 여러 개의 밸류 객체를 가진다.

작업은 애그리거트 단위로 상호작용한다. 이렇게 일관적인 경계를 가지게 되면 일관성 문제가 해소될 수 있다.

업데이트는 애그리거트 단위로 호출되기에 불변 값이 강제되고, 동시성 역시 애그리거트를 기준으로 잠금하여 처리할 수 있다.

 

DDD의 핵심은 애그리거트와 경계, 루트를 식별하는 것이다. 정해진 규칙을 준수해야 도메인 모듈의 모듈화를 통해 성공적인 MSA를 달성할 수 있다.

 

애그리거트 규칙

> 애그리거트 루트만을 참조하라

> 애그리거트 간 참조는 기본키만을 사용해라.

객체 참조 대신 ID 참조를 사용하라는 말이다. 이러면 아그리거트 간 관계가 느슨하게 결합되고 애그리거트 간 경계가 분명해지기 때문에 실수할 여지도 적다. 또한 객체 참조를 통한 사이클이 도는 문제도 방지할 수 있다.

추가적으로 애그리거트가 저장 단위이기에 NoSQL DB에 저장하기도 쉽다.

> 하나의 트랜잭션은 하나의 애그리거트만을 수정하라

한 트랜잭션이 반드시 한 애그리거트를 수정해야 MSA와 잘 맞는 모델이 된다. 다른 애그리거트를 삽입하거나 수정해야 할 일이 생긴다면 이벤트 방식을 통해 결합도를 줄여야만 한다.

 

아래 네모난 것들이 요소들이고 모서리가 둥근 네모가 한 애그리거트를 가리킨다.