유비쿼터스 랭귀지 만들기

우리는 코드와 도메인 전문가가 동일한 모델을 공유해야 한다고 배웠습니다.

이는 우리 설계 안의 무언가가 도메인 전문가의 멘탈 모델의 무언가와 대응되어야 한다는 것입니다.

즉, 도메인 전문가가 무언가를 "주문"이라고 부르는 경우 개발자의 코드에 "주문"이라고 하는 무언가가 있어야

이에 대응하고 동일한 방식으로 동작합니다.

반대로 우리는 도메인 전문가의 모델에서 무언가를 나타내지 않는 것을 디자인에 포함해서는 안됩니다.

이는 OrderFactory, OrderManager, OrderHelper 등과 같은 용어는 없음을 의미합니다.

도메인 전문가는 이 단어의 의미를 모를 것입니다.

물론 일부 기술 용어는 코드베이스에서 발생해야 하지만 디자인의 일부로 이를 노출하는 것은 피해야 합니다.

팀의 모든 사람들이 공유하는 일련의 개념과 어휘를 유비쿼터스 언어(Ubiquitous Language), 즉 "어디서나 사용되는 언어"라고 합니다. 이것은 비즈니스 도메인에 대한 공유 정신 모델을 정의하는 언어입니다. 그리고 이름에서 알 수 있듯 이 언어는 요구 사항뿐만 아니라 설계, 가장 중요한 소스 코드 등 프로젝트의 모든 곳에서 사용해야 합니다.

유비쿼터스 언어의 구성은 도메인 전문가가 지시하는 일방적인 프로세스가 아니라 팀의 모든 구성원 간의 협업입니다.

유비쿼터스 언어가 정적일 것이라고 기대해서는 안 됩니다.

디자인이 발전함에 따라 새로운 용어와 개념을 발견할 준비를 하고 유비쿼터스 언어가 그에 따라 진화하도록 하십시오. 

마지막으로, 모든 영역과 컨텍스트를 포괄하는 단일 유비쿼터스 언어를 가질 수 없다는 사실을 깨닫는 것이 중요합니다.

각 컨텍스트에는 유비쿼터스 언어의 "방언-dialect"이 있으며 동일한 단어가 다른 방언으로 다른 것을 의미할 수 있습니다.

예를 들어, "클래스"는 객체 지향 프로그래밍 영역과 CSS 영역에서 완전히 다른 것을 의미합니다.

"고객" 또는 "제품"과 같은 단어를 다른 맥락에서 동일한 의미로 만들려고 하면 복잡한 요구 사항이 발생할 수 있고

최악의 경우 심각한 설계 오류가 발생할 수 있습니다.

 

실제로 이벤트 스토밍 세션은 이 정확한 문제를 보여줍니다.

모든 참석자는 이벤트를 설명할 때 "주문"이라는 단어를 사용했습니다.

그러나 배송 부서의 "주문" 정의가 청구 부서의 정의와 미묘하게 다른 정의를 찾을 수 있습니다.

배송 부서는 아마도 재고, 주문 수량 등에 관심이 있는 반면

청구 부서는 가격과 비용에 더 관심이 있을 것입니다.

문맥을 지정하지 않고 어디에서나 같은 단어 "주문"를 사용하면 고통스러운 오해에 빠질 수 있습니다.

 

 

도메인 주도 설계의 개념 요약

• 도메인은 우리가 해결하려고 하는 문제와 관련된 지식의 영역 또는 간단히 "도메인 전문가"가 전문적인 영역입니다.
• 도메인 모델은 특정 문제와 관련된 도메인의 측면을 나타내는 일련의 단순화입니다. 도메인 모델은 솔루션 공간의 일부이고 그것이 나타내는 도메인은 문제 공간의 일부입니다.
• 유비쿼터스 랭귀지는 도메인과 연관되어 팀 구성원과 소스 코드가 공유하는 일련의 개념 및 어휘입니다.
• 바운디드 컨텍스트는 솔루션 공간의 서브 시스템으로, 다른 서브 시스템과 구분되는 명확한 경계가 있습니다.
  바운디드 컨텍스트는 종종 문제 공간의 서브 도메인에 해당합니다. 바운디드 컨텍스트에는 고유한 개념과 어휘, 유비쿼터스 언어의 고유 방언도 있습니다.
• 컨텍스트 맵은 바운디드 컨텍스트의 컬렉션과 이들 간의 관계를 보여주는 상위 수준 다이어그램입니다.
• 도메인 이벤트는 시스템에서 발생한 일에 대한 기록입니다. 항상 과거형으로 설명합니다. 이벤트는 종종 추가 활동을 유발합니다.
• 커맨드는 어떤 프로세스가 일어나도록 하는 요청이며 사람이나 다른 이벤트에 의해 트리거됩니다. 프로세스가 성공하면 시스템 상태가 변경되고 하나 이상의 도메인 이벤트가 기록됩니다.
• 도메인 이벤트는 종종 주기적으로 발생할 수 있습니다. (커맨드 없이)