이전 글에서 DDD가 무엇인지 간략히 알아보았다.
그중에서도 바운디드 컨텍스트에 대한 개념을 살펴보았는데,
이번 글에서는 각 바운디드 컨텍스트 간에 모델을 어떻게 공유하고 상호작용하는지 설명하려고 한다.
Contract
바운디드 컨텍스트 간에도 상호작용이 필요하며, 이 상호작용 방식을 컨트랙트(contract)라고 부른다.
바운디드 컨텍스트 간 상호작용 패턴
컨트랙트는 상호작용 방식에 따라 몇 가지 패턴으로 나눌 수 있다. 대표적으로 협력형, 사용자-제공자, 분리형 패턴이 있다.
각 패턴은 바운디드 컨텍스트 간의 의존성과 독립성을 어떻게 유지할지를 결정하는 방식에 따라 구분된다.
협력형(cooporation) 패턴
파트너십 패턴
한 팀은 다른 팀에게 API 변경을 알리고 다른 팀은 충돌 없이 받아들인다.
양 팀 모두 커뮤니케이션이 원할할 때 사용할 수 있는 패턴이다.
공유 커널 패턴
공유할 수 있는 모델을 두고 각 팀이 공유 모델을 사용하는 패턴이다.
공유 모델의 변경은 다른 팀에게 영향이 갈 수 있기 때문에 신중해야 한다.
사용자 - 제공자(customer - supplier) 패턴
- 사용자, 고객은 downstream
- 서비스 제공자는 upstream
순응주의자(conformist) 패턴
업스트림이 노출한 모델을 다운스트림이 받아들이고 사용한다.
충돌 방지 계층(ACL: anticorruption layer) 패턴
제공자의 모델을 그대로 따르지 않고, 다운스트림에서 자신의 하위 도메인에 맞게 변환하여 사용한다.
업스트림의 모델이 비효율적이거나 핵심 모델링을 방해할 경우, 또는 잦은 변경이 예상될 때 유용하다.
오픈 호스트 서비스(OHS) 패턴
업스트림이 다운스트림을 보호하기 위해 공표된 언어를 사용하여 여러개의 방식을 제공한다.
분리형 노선(seperated ways) 패턴
협력이 필요하지 않다고 판단될 때 선택하는 패턴이다.
바운디드 컨텍스트 내에서 독립적으로 문제를 해결하는 비용이 더 빠르다고 판단될 때 사용한다.
이 패턴이 선택되는 이유는 다음과 같다
- 복잡한 모델로 인해 협력이 어려운 경우
- 정치적 이유로 협업이 어려운 경우
- 협업 의지가 없을 때
각 패턴에 정답이 있는 것은 아니며, 상황에 따라 적합한 방식을 선택해야 한다.
모놀리스 서비스를 운영하면서 개발자들도 모르게 패키지를 통해 경계를 나누게 되는 경우가 많다.
이런 상황속에서 도메인 모델을 바로 공유하여 사용하거나, 한쪽 모델의 변경에 다른 쪽도 영향을 받아 함께 변경되기도 하며, 혼란스러운 상황이 생기기도 한다.
결국 바운디드 컨텍스트 개념을 도입하는 이유는 이러한 경계를 명확히 하고, 각 컨텍스트가 독립적이면서도 유연하게 상호작용할 수 있도록 하기 위함이라고 생각한다.
