전략적 설계 - 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, 애자일 프로세스 등을 통해 도메인 모델을 지속적으로 정제하고, 변경 사항을 반영할 수 있다.