2022.08.09 - DDD - 도메인 모델과 바운디드 컨텍스트, 이벤트, CQRS

[LuterGS]

도메인 모델과 바운디드 컨텍스트

도메인을 완벽하게 표현하는 단일 모델을 만들기는 쉽지 않다. 또, 같은 이름이더라도 도메인에 따라 다른 특성을 가지는 경우가 있다. 이럴 때는 다음과 같이 해야 한다.

• 하위 도메인마다 모델을 만들어야 함
• 각 모델은 명시적으로 구분되는 경계를 가짐 (섞이지 않음)

모델은 특정 컨텍스트 하에 완전한 의미를 가진다. 이 컨텍스트를 바운디드 컨텍스트 라고 한다.

바운디드 컨텍스트

• 바운디드 컨텍스트는 모델의 경계를 결정한다.
• 한 개의 바운디드 컨텍스트는 논리적으로 한 개의 모델을 가진다.
• 명확하게 구분되지 않은 경우, 두 하위 도메인을 하나의 바운디드 컨텍스트에서 구현하기도 한다.
• 한 개의 바운디드 컨텍스트가 여러 하위 도메인을 포함하더라도, 하위 도메인마다 구분되는 패키지를 가지도록 해야 한다.
• 바운디드 컨텍스트는 구현하는 하위 도메인에 알맞은 모델을 포함한다.
  
• 바운디드 컨텍스트는 도메인 기능을 제공하는 데 필요한 모든 요소를 포함한다.
• 모든 바운디드 컨텍스트를 도메인 주도로 개발할 필요는 없다.
• 각 바운디드 컨텍스트는 서로 다른 구현 기술을 사용할 수 있다.
• 바운디드 컨텍스트간 통합이 필요할 수 있다.
  • 모델간 변환이 어려우면 별도 변환기를 둘 수 있다.
  • MSA 로 바운디드 컨텍스트를 구현할 수 있다.
    
• 바운디드 컨텍스트 간 관계로는 Downstream / Upstream 이 있다 (의존)
• 컨텍스트 맵을 활용하여 바운디드 컨텍스트간의 관계를 파악할 수 있다.

[LuterGS]

이벤트

시스템 간 강결합이 일어나려고 할 때, 이벤트를 통해 처리할 수 있다

• Spring 에서 지원하는 EventHandler 등을 통해 강결합이 일어날 수 있는 연계되는 작업을 이벤트로 처리할 수 있다.

[LuterGS]

CQRS

상태 변경 모델과, 상태 제공 모델을 분리하는 것

• 상태 변경과 조회는 겹치지 않는 경우가 있어, 두 경우를 동시에 만족하려면 모델이 불필요하게 복잡해진다.
• 이 때, 변경과 조회 모듈을 사진과 같이 분리할 수 있다.
• 조회 모듈의 경우 조회에 최적화된 프레임워크나 기술을, 변경 모듈은 그와 다른 기술을 다르게 가져갈 수 있다는 장점이 있다.
• 조회 모듈의 경우 응용 서비스가 필요 없을 수 있다 (데이터를 조회하는 기능일 경우)
• 웹서비스의 경우, CQRS 를 적용하는 것이 일반적이다.
• 장점
  • 각각의 기능에 따른 코드가 분리되므로, 단일 모델로 있을 때보다 도메인 로직에 집중할 수 있다
  • 조회 성능을 향상시킬 수 있다.
• 단점
  • 구현해야 할 코드가 많아진다
  • 더 많은 구현 기술이 들어간다