전략적 설계 - UBIQUITOUS LANGUAGE
유비쿼터스 언어
도메인에서 사용하는 용어를 코드에 반영하지 않으면 그 코드는 개발자에게 코드의 의미를 해석해야 하는 부담을 준다. (그 전에 도메인 용어에 대해 다른 도메인 관련자들과 충분한 논의가 이루어져야 한다)
코드의 가독성을 높여서 코드를 분석하고 이해하는 시간을 절약한다.
용어가 정의 될 때마다 용어 사전에 이를 기록하고 명확하게 정의 함으로써 추후 또는 다른 사람들도 공통된 언어를 사용할 수 있도록 한다. (용어 사전 정의!)
효과적인 모델링
사업팀에게는 너무 추상적이라서요.
사업팀은 객체를 이해하지 못해요.
사업팀이 쓰는 용어로 된 요구 사항을 만들어야 해요.
사업팀도 해당 모델을 이해하지 못한다면 모델이 뭔가 잘못된 것이다.
UML(Unified Modeling Language)
모델 기반 의사소통은 UML 상의 다이어그램으로 한정돼서는 안 된다.
DDD에서 "모델 기반 의사소통"은 UML 다이어그램만으로 이루어지는 것이 아니라, 코드, 대화, 이벤트 스토밍, 테스트 등 다양한 방식으로 도메인 모델을 지속적으로 발전시키는 과정을 의미한다. UML 다이어그램은 그 과정에서 하나의 보조 도구일 뿐, 모델 자체가 될 수는 없다.
UML 사용 시 주의점
1. 모델의 본질: UML은 단순한 표현 도구일 뿐
UML 다이어그램은 시스템의 구조와 흐름을 시각적으로 표현하는 데 유용하지만, 그것만으로는 도메인 모델을 온전히 표현하기 어렵다.
도메인 모델은 코드, 테스트, 문서, 팀원 간의 대화, 이벤트 스토밍과 같은 다양한 방식으로 발전하고 공유될 수 있어야 한다.
2. 모델은 코드 속에서 구현되어야 한다
모델은 UML 다이어그램 같은 문서에서만 존재하는 것이 아니라, 실제 코드와 일치해야 한다.
모델이 코드로 구현되지 않으면, 다이어그램은 단순한 이상적인 설계 문서에 불과할 뿐이며 시간이 지나면서 실제 코드와 괴리가 발생할 수 있다.
3. 도메인 전문가와 개발자 간의 지속적인 협업이 필요
도메인 모델은 단순히 개발자들만의 것이 아니라, 도메인 전문가와의 협력을 통해 지속적으로 발전해야 한다. (도메인 모델은 살아있는 생명체 같이 계속해서 변화한다!)
이 과정에서 유비쿼터스 언어(Ubiquitous Language) 를 활용한 논의, 이벤트 스토밍, 프로토타이핑 등이 중요한 역할을 한다.
UML 다이어그램이 이러한 협업을 완전히 대체할 수는 없다.
4. 정적인 문서보다 살아있는 모델이 중요
UML 다이어그램은 정적인 모델을 표현하는데, 이는 현실 세계의 복잡한 도메인 논리를 충분히 반영하기 어려울 수 있다.
살아있는 코드, 테스트 케이스, 협업 도구(Git, ADR, Wiki 등)를 통해 도메인 모델을 지속적으로 개선하는 것이 중요하다.
5. 실제 적용 사례
많은 DDD 실천가들은 UML 다이어그램을 최소한으로 사용하고, 코드와 테스트를 기반으로 도메인 모델을 발전시키는 접근 방식을 선호한다.
이벤트 스토밍, TDD, 애자일 프로세스 등을 통해 도메인 모델을 지속적으로 정제하고, 변경 사항을 반영할 수 있다.
Last updated