DDD(Domain Driven Design) - Domain, BC (Bounded Context), Context Mapping, Ubiquitous Language

프로젝트가 진행됨에 따라, 서비스 혹은 회사가 성장함에 따라 요구사항은 다양해지고 기존의 시스템에도 변경이 일어난다. 이는 불가피하게 시스템의 복잡성을 증가를 수반하게 된다. 따라서, 시간이 지날수록 클린 코드와 클린 아키텍쳐를 이룰 수 없게 될지 모른다. 이를 Software Entropy 라고 부른다.
https://www.webopedia.com/TERM/S/software_entropy.html

시스템에 수많은 변경과 반영이 일어나면서, 적절한 관심사 분리와 클래스와 모듈간의 결합도를 낮추는것을 유지하는것은 점점 더 어려워 지며, 아키텍쳐 레벨에서 가이드라인을 강제하지 않을 경우 시스템의 새로운 기능 및 변경이 더이상 힘들어질 수 있다.

전통적인 MVC (Model-View-Controller) 아키텍쳐에선, "M" Layer 는 모든 비즈니스 로직을 가지고 있다. 그러나 MVC 에서에는 깔끔하고 적절하게 책임의 경계를 이루기 어렵다. 몇가지 패턴들은 해당 문제를 완화시킬 수 있지만, 여전히 로직과 책임이 새어나갈 여지가 있다.

반대로, 비즈니스 전문가들과 요구 사항을 수집하고, 기술적인 팀과 비기술적인 팀 사이에서 합의점을 찾아는 과정에서, 시스템을 설계하고 수행할 때 양측은 서로 자신의 부분에 맞게 잘못 해석할 여지가 있다. 결과적으로 이는 원래의 목표와는 다르게 프로젝트에 반영될 여지가 충분하다.

그리고, 변수와 클래스 메서드 등을 네이밍할 때 개발자들이 가장 힘들어 하는 부분이다. 우리는 다른 개발자가 명확하게 코드에서 작성자의 의도를 이해할수 있도록 해야하며, 또한 비즈니스 관계자(기획자, 테스터 등)들 및 이해관계자들과 의사소통을 할 때도 충분하게 활용할 수 있어야한다.

DDD 는 소프트웨어 프로젝트에서 충돌하는 기술팀과 비기술팀을 조정하면서 동시에 성공적인 시스템 구축을 쉽게하는 기술들과 패턴을 제안하며 기존의 문제들을 해결할 수 있다.

DDD 란 무엇인가 ?

먼저 Domain 이 무엇인지 알아보자.
->  Application 이 비즈니스 문제를 해결하기 위해서 작동하며 공통 요구 사항과 용어 및 기능 집합을 정의하는 특정 활용 혹은 지식 영역이다. 굉장히 추상적이다. 단적인 예로 특정 상품을 판매하는 어플리케이션이 있다고 가정해보자. 상품을 구매하는 주체가 있을것이다. 이를 회원이라고 가정한다면, 회원이라는 도메인이 존재할 수 있다.

자, 그렇다면 돌아와서 DDD 는 무엇인가?
주로 비즈니스 문제와 이를 해결하는 로직을 엄격하게 구성하는 방법에 중점을 둔다.
끊임없이 진화하는 비즈니스 모델과 시스템 구현을 연결하여 인프라 기술과 같이 관련성이 적은 부분은 뒤로 남겨둔 채 유연하게 적용할 수 있도록 하는 소프트웨어 디자인 방식이다.

전략적인 설계

지속적이고 많은 업데이트를 통해 시스템이 커지고 변경됨에 따라, 시스템의 복잡성 또한 증가하며, 유지보수에 어려움이 수반된다. 그래서, 이러한 시스템을 이해하고 제어하기위해 엄격한 전략이 필요하다. 서로 협력하는 Bounded Context 로 세분화가 필요하다. 개념과 코드안에서 통일된 스스로의 모델을 가지며, 효율적인 방법으로 복잡성을 피할수 있다.

Bounded Context ?

바운디드 컨텍스트란 Application 의 부분이나 비즈니스적인 도메인 혹은 내부의 팀이 될 수도 있고, 코드를 기준으로 나뉠수도 있는 개념적인 경계이다. 따라서 Application 을 여러 바운디드 컨텍스트로 어떻게 설계하는지는 매우 중요하다. 어떻게 설계하냐에 따라 장점보다 단점이 증가할 수도 있다. 바운디드 컨텍스트는 관련된 components 와 개념들의 집합이다. 바운디드 컨텍스트에 따라 유사한 개념의 애매함을 피할 수 있다는 장점이 있다.

예를 들어보자. Account 라는 class 가 있다고 했을 때, context 에 따라 매우 다르게 해석될 수 있다.
은행과 같이 금융 Application 에서는 Account 는 계좌로 지칭될 수 있으며, 반대로 일반 전자상거래 Application 에서 (만약 회원을 Account 라는 유비쿼터스 랭귀지를 지칭했다면) Account 는 일반 계정을 의미할 수 있다.

따라서, 프로젝트에서 팀을 바운디드 컨텍스트에 의해서 나눠질 수 있으며,  각 팀은 전문화된 도메인 전문가와 관련 개발자 및 관계자를 가진다.

https://martinfowler.com/bliki/BoundedContext.html

Context Mapping ?

프로젝트 내에서 각각의 바운디드 컨텍스트들을 시각적으로 나타내고 식별할 수 있도록 나타내는 것을 의미한다. 컨텍스트 매핑은 바운디드 컨텍스트들과 해당 팀들이 어떻게 연관되어 있으며 의사소통 하는 방법을 쉽게 이해할수 있도록 도와준다. 시스템의 설계도를 개념적으로 어떻게 분할되어 있는지 쉽게 확인이 가능하다. 바운디드 컨텍스트 간의 관계는 설계 요구 사항 및 기타 프로젝트 특정 제약 조건에 따라 다를 수 있다.



DDD 는 협업의 기술적인 부분 뿐만 아니라, 비즈니스 지식에 관련된 모든 관계자들의 협업을 통해 효율적으로 도메인을 모델링 하는 것을 제안하고 있다. Evans 는 Domain Model 을 "is not only the knowledge in a domain expert's head; it is a rigorously organized and selective abstraction of that knowledge." 라고 했다.

개발자들은 도메인 전문가들과 끊임없이 도메인 모델의 의도를 정제하는 과정을 거친다. 기계적으로 코드를 생산하는 것이 아니라, 개발자와 도메인 전문가가 해결하려고 하는 비즈니스 문제의 원칙과 중요한 상세사항들을 배울 수 있도록 강제한다.

Ubiquitous Language ?

이렇게 도메인 전문가와 기술 팀이 협업하기 위해서는, 도메인 모델은 기술 전문 용어로 비즈니스에 참여하는 언어를 사용해야 하며 모든 팀 구성원이 이해하고 동의 할 수 있는 중간 지점을 찾아야한다. 이를 Ubiquitous Language 라고 한다. 잘 정의된 유비쿼터스 랭귀지는 기술팀과 비즈니스 팀 사이의 모든 상호 작용들을 덜 애매하게 만들며 더 효율적으로 만들게 할 것이다.

궁극적으로 이러한 유비쿼터스 랭귀지는 코드속에 스며들게 된다.