DDD(도메인 중심 설계)는 소프트웨어 시스템이 작동하는 문제 영역을 이해하고 모델링하는 데 초점을 맞춘 소프트웨어 개발 접근 방식입니다. 이는 도메인의 복잡함과 복잡성에 대한 깊은 이해를 개발하기 위해 도메인 전문가와 긴밀히 협력하는 것의 중요성을 강조합니다. DDD는 개발자가 소프트웨어 설계에서 도메인 개념을 효과적으로 포착하고 표현하는 데 도움이 되는 일련의 원칙, 패턴 및 사례를 제공합니다.

자바의 역사

도메인 중심 설계(DDD)의 주요 주제

• 도메인 기반 디자인(DDD)이란 무엇입니까?
• 도메인 지식의 중요성
• 도메인 중심 디자인(DDD)의 전략적 디자인
• 도메인 중심 설계(DDD)의 전술적 설계 패턴
• 도메인 중심 설계(DDD)의 이점
• 도메인 중심 설계(DDD)의 과제
• 도메인 기반 설계(DDD) 사용 사례
• 도메인 기반 설계(DDD)의 실제 사례

도메인 기반 디자인(DDD)이란 무엇입니까?

도메인

이는 소프트웨어 시스템이 해결하기 위해 구축되고 있는 주제 영역 또는 문제 공간을 나타냅니다. 이는 소프트웨어가 모델링하거나 지원하려는 실제 개념, 규칙 및 프로세스를 포함합니다. 예를 들어, 뱅킹 애플리케이션에서 도메인에는 계좌, 거래, 고객 및 은행 운영과 관련된 규정과 같은 개념이 포함됩니다.

중심의

Driven은 소프트웨어 시스템의 설계가 도메인의 특성과 요구 사항에 의해 안내되거나 영향을 받는다는 것을 의미합니다. 즉, 설계 결정은 기술적인 고려 사항이나 구현 세부 사항에만 의존하기보다는 해당 영역에 대한 깊은 이해를 바탕으로 이루어집니다.

설계

디자인은 소프트웨어 시스템에 대한 계획이나 청사진을 만드는 프로세스를 말합니다. 여기에는 시스템이 어떻게 구성될 것인지, 다양한 구성 요소가 어떻게 상호 작용할 것인지, 시스템이 어떻게 기능을 수행할 것인지에 대한 결정이 포함됩니다. 기능의 그리고 비기능적 요구 사항. 도메인 중심 설계의 맥락에서는 도메인의 구조와 동작을 정확하게 반영하는 방식으로 소프트웨어를 설계하는 데 중점을 둡니다.

도메인 중심 설계(Domain-Driven Design)는 프로그래머가 도입한 개념입니다. 에릭 에반스 2004년 그의 책에서 도메인 중심 설계: 소프트웨어 핵심의 복잡성 해결

도메인 지식의 중요성

우리가 모든 최신 기술 스택과 인프라를 사용하여 소프트웨어를 설계했고 우리의 소프트웨어 설계 아키텍처가 놀랍지만 이 소프트웨어를 시장에 출시할 때 우리 시스템이 훌륭한지 여부를 결정하는 것은 궁극적으로 최종 사용자라고 가정해 보겠습니다. 또한 시스템이 비즈니스 요구 사항을 해결하지 못한다면 누구에게도 쓸모가 없습니다. 외관이 얼마나 예쁘든, 인프라가 얼마나 잘 구축되어 있든 상관없습니다.

에 따르면 에릭 에반스 , 우리가 소프트웨어를 개발할 때 우리의 초점은 주로 기술에 있어서는 안 되며, 오히려 주로 비즈니스에 맞춰져야 합니다. 기억하다,

고객이 원하는 것이 무엇인지 아는 것은 고객의 일이 아니다 - 스티브 잡스

powershell 여러 줄 주석

도메인 중심 디자인(DDD)의 전략적 디자인

도메인 중심 디자인(DDD)의 전략적 디자인은 문제 도메인에 맞는 방식으로 소프트웨어 시스템의 전체 아키텍처와 구조를 정의하는 데 중점을 둡니다. 도메인 개념을 구성하는 방법, 시스템을 관리 가능한 부분으로 분할하는 방법, 다양한 구성 요소 간의 명확한 경계를 설정하는 방법과 같은 높은 수준의 문제를 다룹니다.

도메인 중심 설계(DDD)의 전략적 설계에 포함된 몇 가지 주요 개념을 살펴보겠습니다.

1. 제한된 컨텍스트

• 제한된 컨텍스트는 특정 모델이나 언어가 일관되게 적용되는 전체 문제 영역 내의 특정 영역을 나타냅니다.
• 시스템의 서로 다른 부분은 동일한 용어에 대해 서로 다른 의미를 가질 수 있으며, 제한된 컨텍스트는 해당 용어가 특정 의미를 갖는 명시적인 경계를 정의합니다.
• 이를 통해 팀은 혼란이나 불일치를 초래하지 않고 특정 상황에 맞는 모델을 개발할 수 있습니다.
• 바인딩된 컨텍스트는 크고 복잡한 도메인을 더 작고 관리하기 쉬운 부분으로 분할하여 복잡성을 관리하는 데 도움이 됩니다.

2. 컨텍스트 매핑

• 컨텍스트 매핑은 서로 다른 바인딩된 컨텍스트 간의 관계와 상호 작용을 정의하는 프로세스입니다.
• 여기에는 컨텍스트 간의 중복 또는 통합 영역을 식별하고 컨텍스트 간의 통신 채널 및 합의를 설정하는 작업이 포함됩니다.
• 컨텍스트 매핑은 시스템의 서로 다른 부분이 서로 명확한 경계를 유지하면서 효과적으로 협업할 수 있도록 보장합니다.
• 파트너십, 공유 커널, 고객-공급자 등 컨텍스트 매핑에는 다양한 패턴과 기술이 있습니다.

3. 전략적 패턴

• 전략적 패턴은 문제 영역에 맞게 소프트웨어 시스템의 아키텍처를 구성하기 위한 일반적인 지침 또는 원칙입니다.
• 이러한 패턴은 복잡한 시스템을 설계할 때 발생하는 일반적인 문제를 해결하는 데 도움이 되며 시스템을 효과적으로 구성하기 위한 입증된 접근 방식을 제공합니다.
• 전략적 패턴의 예로는 집계, 도메인 이벤트 및 부패 방지 계층이 있습니다.
• 이러한 패턴은 도메인 중심 설계에서 반복되는 문제에 대한 솔루션을 제공하고 시스템 아키텍처가 기본 도메인 개념을 정확하게 반영하도록 보장합니다.

4. 공유 커널

• 공유 커널은 서로 다른 바인딩된 컨텍스트 간의 공통성 영역을 식별하고 여러 컨텍스트에서 사용되는 도메인 모델의 공유 하위 집합을 설정하는 전략적 패턴입니다.
• 이 공유 하위 집합 또는 커널은 각 컨텍스트가 고유한 모델을 유지할 수 있도록 하면서 컨텍스트 간의 협업과 통합을 촉진하는 데 도움이 됩니다.
• 공유 커널은 컨텍스트 간에 종속성을 도입하고 주의 깊게 관리하지 않으면 결합으로 이어질 수 있으므로 신중하게 사용해야 합니다.

5. ACL(부패방지층)

• 부패 방지 계층은 다른 모델이나 언어를 사용하는 외부 또는 레거시 시스템의 영향으로부터 시스템을 보호하는 데 도움이 되는 또 다른 전략적 패턴입니다.
• ACL은 외부 시스템과 핵심 도메인 모델 간의 변환 계층 역할을 하여 호환성을 보장하기 위해 필요에 따라 데이터와 메시지를 변환합니다.
• 이를 통해 핵심 도메인 모델은 순수하게 유지되고 문제 도메인에 집중하는 동시에 필요에 따라 외부 시스템과 통합될 수 있습니다.

6. 유비쿼터스 언어

유비쿼터스 언어는 소프트웨어 시스템 개발에 참여하는 모든 이해관계자가 일관되고 보편적으로 사용되는 공유 어휘 또는 언어를 말합니다. 이 언어는 해당 분야의 지식과 개념을 정확하게 표현하는 용어, 구문, 개념으로 구성됩니다.

유비쿼터스 언어의 주요 원칙 중 일부는 다음과 같습니다.

• 공유된 이해 : 유비쿼터스 언어의 주요 목표는 개발자, 도메인 전문가, 비즈니스 분석가 및 이해관계자를 포함하여 개발팀의 모든 구성원이 문제 도메인에 대한 공유된 이해를 구축하는 것입니다. 공통 언어를 사용함으로써 관련된 모든 사람이 도메인 개념과 요구 사항을 보다 효과적이고 정확하게 전달할 수 있습니다.
• 일관성과 명확성 : 유비쿼터스 언어는 정확하고 명확한 용어를 사용하여 의사소통의 일관성과 명확성을 촉진합니다. 언어의 각 용어나 문구는 명확하고 합의된 의미를 가져야 합니다.
• 비즈니스 개념과의 연계 : DDD에서 사용되는 언어는 비즈니스 영역에서 사용되는 용어 및 개념과 밀접하게 일치해야 합니다. 도메인 전문가가 문제 도메인에 대해 생각하고 이야기하는 방식을 반영하여 소프트웨어가 실제 개념과 프로세스를 정확하게 나타내도록 보장해야 합니다.
• 진화적 성격 : 유비쿼터스 언어는 고정되어 있지 않지만 팀이 해당 도메인에 대해 더 깊이 이해하고 요구 사항이 변경됨에 따라 시간이 지남에 따라 진화합니다. 새로운 통찰, 발견 또는 비즈니스 우선순위의 변화를 반영하도록 조정되어야 하며, 개발 프로세스 전반에 걸쳐 언어가 관련성과 최신 상태를 유지하도록 보장해야 합니다.

도메인 중심 설계(DDD)의 전술적 설계 패턴

DDD(도메인 중심 설계)에서 전술적 설계 패턴은 소프트웨어 시스템 내에서 도메인 모델을 구조화하고 구성하는 데 사용되는 특정 전략 또는 기술입니다. 이러한 패턴은 개발자가 도메인의 복잡성을 효과적으로 포착하는 동시에 유지 관리 가능성, 유연성 및 확장성을 향상시키는 데 도움이 됩니다.

DDD의 주요 전술적 디자인 패턴 중 일부를 살펴보겠습니다.

1. 실체

엔터티는 고유한 ID와 수명 주기를 가진 도메인 개체입니다. 엔터티는 고유 식별자와 변경 가능한 상태로 특징지어집니다. 이는 도메인 내의 특정 개념과 관련된 동작 및 데이터를 캡슐화합니다.

예를 들어, 은행 애플리케이션에서BankAccount>엔터티에는 자금 입금, 인출 또는 이체 방법과 함께 계좌 번호, 잔액, 소유자와 같은 속성이 있을 수 있습니다.

2. 가치 객체

값 개체는 개념적으로 변경할 수 없는 값을 나타내는 도메인 개체입니다. 엔터티와 달리 값 개체에는 고유한 ID가 없으며 일반적으로 엔터티의 속성이나 속성을 나타내는 데 사용됩니다. 값 개체는 ID가 아닌 속성을 기준으로 동등 비교가 가능합니다.

예를 들어,Money>값 개체는 통화 유형 및 금액과 같은 속성을 캡슐화하여 특정 통화 금액을 나타낼 수 있습니다.

3. 집계

• 집계는 데이터 일관성 및 트랜잭션 무결성을 위해 단일 단위로 처리되는 도메인 개체의 클러스터입니다.
• 집계는 하나 이상의 엔터티와 값 개체로 구성되며, 하나의 엔터티는 집계 루트로 지정됩니다.
• 집계 루트는 집계의 내부 상태에 액세스하고 수정하기 위한 진입점 역할을 합니다.
• 집계는 도메인 모델 내에서 일관성 경계를 적용하여 관련 개체에 대한 변경 사항이 원자적으로 이루어지도록 합니다.

예를 들어, 전자상거래 시스템에서는Order>집계는 다음과 같은 엔터티로 구성될 수 있습니다.OrderItem>그리고Customer>, 와 더불어Order>집계 루트 역할을 하는 엔터티입니다.

4. 저장소

• 저장소는 도메인 모델에서 데이터 액세스 및 지속성 논리를 추상화하기 위한 메커니즘입니다.
• 리포지토리는 도메인 개체를 쿼리하고 저장하기 위한 표준화된 인터페이스를 제공하여 데이터 검색 또는 저장 방법에 대한 세부 정보를 숨깁니다. 리포지토리는 데이터베이스나 외부 서비스와 같은 도메인 개체와 기본 데이터 저장 메커니즘 간의 변환 논리를 캡슐화합니다.
• 데이터 액세스 문제에서 도메인 모델을 분리함으로써 리포지토리는 더 큰 유연성과 유지 관리 가능성을 제공합니다.

예를 들어,CustomerRepository>쿼리하고 저장하는 방법을 제공할 수 있습니다.Customer>엔터티.

5. 공장

• 공장은 창조 패턴 복잡한 도메인 개체의 인스턴스를 생성하기 위한 논리를 캡슐화하는 데 사용됩니다. 팩토리는 개체 인스턴스화 프로세스를 추상화하여 클라이언트가 구성 세부 사항을 알 필요 없이 개체를 만들 수 있도록 합니다.
• 팩토리는 복잡한 초기화 논리가 필요하거나 여러 단계가 포함된 개체를 만드는 데 특히 유용합니다.

예를 들어,ProductFactory>인스턴스 생성을 담당할 수 있습니다.Product>기본 구성이 있는 엔터티.

6. 서비스

• 서비스는 특정 엔터티나 값 개체에 자연스럽게 속하지 않는 동작이나 작업을 나타내는 도메인 개체입니다.
• 서비스는 여러 개체에서 작동하거나 개체 간의 상호 작용을 조정하는 도메인 논리를 캡슐화합니다.
• 서비스는 일반적으로 상태 비저장이며 특정 작업을 수행하거나 도메인 규칙을 적용하는 데 중점을 둡니다.

예를 들어,OrderService>주문 처리, 할인 적용, 배송비 계산 방법을 제공할 수도 있습니다.

도메인 중심 설계(DDD)의 이점

• 공유된 이해 :
  • 이는 도메인 전문가, 개발자 및 이해관계자 간의 협업을 장려합니다.
  • 유비쿼터스 언어를 통해 문제 영역에 대한 공유된 이해를 장려함으로써 팀은 보다 효과적으로 의사소통하고 소프트웨어가 비즈니스의 요구 사항과 요구 사항을 정확하게 반영하는지 확인할 수 있습니다.
• 핵심 도메인에 집중 :
  • 이는 팀이 비즈니스에 가장 큰 가치를 제공하는 시스템 영역인 애플리케이션의 핵심 도메인을 식별하고 우선 순위를 지정하는 데 도움이 됩니다. 핵심 도메인에 개발 노력을 집중함으로써 팀은 비즈니스 목표를 직접적으로 해결하고 소프트웨어를 경쟁사와 차별화하는 기능을 제공할 수 있습니다.
• 변화에 대한 회복력 :
  • 문제 영역의 고유한 복잡성과 불확실성을 반영하는 방식으로 영역을 모델링하여 변화에 탄력적인 소프트웨어 시스템을 설계하는 것을 강조합니다.
  • 소프트웨어 개발의 자연스러운 부분으로 변화를 수용함으로써 팀은 진화하는 비즈니스 요구 사항과 시장 상황에 보다 효과적으로 대응할 수 있습니다.
• 우려사항의 명확한 분리 :
  • DDD는 도메인 논리, 인프라 문제, 사용자 인터페이스 문제 간의 문제를 명확하게 분리하도록 권장합니다. 기술적 세부 사항 및 인프라 문제에서 도메인 논리를 분리함으로써 팀은 특정 구현 세부 사항이나 기술 선택에 관계없이 깔끔하고 집중된 도메인 모델을 유지할 수 있습니다.
• 향상된 테스트 가능성 :
  • 경계와 동작이 잘 정의된 도메인 개체의 사용을 촉진하여 도메인 논리의 정확성을 확인하는 더 나은 집중 테스트를 더 쉽게 작성할 수 있습니다.
  • 테스트 가능성을 염두에 두고 소프트웨어 시스템을 설계함으로써 팀은 코드베이스 변경이 안전하고 예측 가능하도록 보장하여 회귀 또는 의도하지 않은 부작용이 발생할 위험을 줄일 수 있습니다.
• 복잡한 비즈니스 규칙 지원 :
  • 도메인 모델 내에서 복잡한 비즈니스 규칙과 워크플로우를 모델링하고 구현하기 위한 패턴과 기술을 제공합니다.
  • 도메인 모델에서 비즈니스 규칙을 명시적으로 표현함으로써 팀은 소프트웨어가 비즈니스 도메인의 복잡성을 정확하게 반영하고 도메인별 제약 조건 및 요구 사항을 적용하는지 확인할 수 있습니다.
• 비즈니스 목표와의 조화 :
  • 궁극적으로 소프트웨어 개발 노력을 비즈니스의 전략적 목표 및 목표에 맞추는 것을 목표로 합니다. 문제 영역을 이해하고 모델링하는 데 집중함으로써 팀은 비즈니스 목표를 직접 지원하고 혁신을 주도하며 이해관계자와 최종 사용자를 위한 가치를 창출하는 소프트웨어 솔루션을 제공할 수 있습니다.

도메인 중심 설계(DDD)의 과제

• 복잡성 :
  • DDD는 특히 크고 복잡한 도메인에서 복잡성을 초래할 수 있습니다.
  • 복잡한 비즈니스 도메인을 정확하게 모델링하려면 해당 도메인에 대한 깊은 이해가 필요하며 모호함과 불확실성을 처리해야 할 수도 있습니다. 이러한 복잡성을 효과적으로 관리하려면 신중한 계획, 협업 및 전문 지식이 필요합니다.
• 유비쿼터스 언어 채택 :
  • 도메인 개념을 정확하게 표현하는 공유 어휘인 유비쿼터스 언어를 확립하고 유지하는 것은 어려울 수 있습니다. 도메인 용어와 의미를 식별하고 동의하려면 개발자와 도메인 전문가 간의 협력이 필요합니다.
  • 유비쿼터스 언어에 대한 합의를 달성하려면 의사소통 장벽을 극복하고 용어와 관점의 차이를 조정해야 할 수도 있습니다.
• 제한된 컨텍스트 정렬 :
  • 크고 복잡한 도메인에서는 도메인의 여러 부분에 고유한 모델과 제한된 컨텍스트가 있을 수 있습니다. 이러한 제한된 컨텍스트를 정렬하고 이들 간의 일관성을 보장하는 것은 어려울 수 있습니다.
  • 불일치와 충돌을 피하기 위해 도메인의 서로 다른 부분에서 작업하는 팀 간의 명확한 의사소통, 협업 및 조정이 필요합니다.
• 기술적 복잡성 :
  • DDD 원칙과 패턴을 효과적으로 구현하려면 새로운 기술, 프레임워크, 아키텍처 접근 방식을 채택해야 할 수도 있습니다. DDD를 기존 시스템 또는 레거시 코드베이스와 통합하는 것은 복잡할 수 있으며 DDD 원칙에 맞게 기존 코드를 리팩토링하거나 재설계해야 할 수도 있습니다.
  • DDD 채택의 성공을 보장하려면 성능, 확장성, 유지 관리 가능성과 같은 기술적 과제를 신중하게 해결해야 합니다.
• 변화에 대한 저항 :
  • DDD를 도입하면 기존 개발 접근 방식에 익숙하거나 DDD가 지나치게 복잡하거나 비실용적이라고 인식하는 팀 구성원의 저항에 직면할 수 있습니다.
  • 변화에 대한 저항을 극복하려면 DDD의 이점을 입증하고 우려 사항과 회의론을 해결하기 위한 효과적인 의사소통, 교육 및 리더십이 필요합니다.
• 과도한 엔지니어링 :
  • DDD를 적용할 때 팀이 복잡한 도메인 개념을 모델링하고 불필요한 추상화 또는 복잡성을 도입하는 데 너무 집중하는 경우 과도한 엔지니어링의 위험이 있습니다. 디자인과 구현이 지나치게 복잡해지는 것을 방지하려면 단순성과 표현력 사이의 적절한 균형을 유지하는 것이 중요합니다.

도메인 기반 설계(DDD) 사용 사례

• 금융 및 은행 :
  • 금융 부문에서 DDD는 복잡한 금융 상품, 거래, 규제 요구 사항을 모델링하는 데 사용될 수 있습니다. DDD는 계정, 거래, 포트폴리오 등 도메인 개념을 정확하게 표현함으로써 금융 시스템의 무결성과 일관성을 보장하는 데 도움이 됩니다. 또한 더 나은 위험 관리, 규정 준수 및 보고가 가능해집니다.
• 전자상거래 및 소매 :
  • 전자상거래 플랫폼은 제품 카탈로그, 재고 관리, 가격 책정, 고객 주문과 같은 복잡한 도메인 개념을 다루는 경우가 많습니다. DDD는 이러한 개념을 효과적으로 모델링하여 맞춤형 추천, 동적 가격 책정, 간소화된 주문 처리 등의 기능을 지원합니다.
• 의료 및 생명 과학 :
  • 의료 분야에서 DDD는 환자 기록, 의료 진단, 치료 계획 및 의료 워크플로를 모델링하는 데 사용될 수 있습니다. DDD는 환자 인구통계, 병력, 임상 프로토콜 등의 도메인 개념을 정확하게 표현함으로써 강력한 전자 건강 기록(EHR) 시스템, 의료 영상 플랫폼, 원격 의료 애플리케이션 개발을 가능하게 합니다.
• 보험 :
  • 보험 회사는 다양한 상품, 정책, 청구 및 인수 프로세스를 관리합니다. DDD는 정책 관리, 청구 처리, 위험 평가, 계리 분석과 같은 기능을 활성화하여 이러한 복잡한 도메인 개념을 모델링하는 데 도움을 줄 수 있습니다.
• 부동산 및 자산 관리 :
  • 부동산 및 자산 관리에는 다양한 자산, 임대, 임차인, 유지 관리 요청 및 금융 거래를 처리하는 작업이 포함됩니다. DDD는 부동산 목록, 임대 관리, 임차인 포털 및 자산 추적과 같은 기능을 활성화하여 이러한 도메인 개념을 효과적으로 모델링하는 데 도움이 될 수 있습니다.

도메인 기반 설계(DDD)의 실제 사례

문제 설명

우리가 RideX라는 차량 공유 애플리케이션을 개발 중이라고 가정해 보겠습니다. 이 시스템을 통해 사용자는 탑승을 요청할 수 있고, 운전자는 탑승 요청을 수락할 수 있으며, 사용자와 운전자 간의 탑승 조정이 용이해집니다.

리눅스 운영 체제

유비쿼터스 언어

1. 사용자 : RideX 플랫폼을 통해 차량 서비스를 요청하는 개인을 말합니다.
2. 운전사 : RideX 플랫폼을 통해 이용자에게 차량 서비스를 제공하는 개인을 말합니다.
3. 탑승 요청 : 승차 위치, 목적지, 승차 선호 사항 등의 세부 정보를 지정하여 사용자의 승차 요청을 나타냅니다.
4. 타다 : 승차 및 하차 위치, 요금, 기간 등의 세부정보를 포함하여 단일 탑승 인스턴스를 나타냅니다.
5. 승차 상태 : 요청됨, 수락됨, 진행 중, 완료됨 등 라이드의 현재 상태를 나타냅니다.

제한된 컨텍스트

1. 승차 관리 컨텍스트 : 차량 요청, 드라이버에 대한 차량 배정, 차량 상태 업데이트 등 차량 서비스의 수명주기를 관리하는 역할을 담당합니다.
2. 사용자 관리 컨텍스트 : 사용자 인증, 등록, 탑승 이력, 결제 수단 등 사용자별 기능을 처리합니다.
3. 드라이버 관리 컨텍스트 : 운전자 인증, 등록, 가용성 상태, 수입, 평점 등 운전자별 기능을 관리합니다.

엔터티 및 값 개체

1. 사용자 엔터티 : 사용자 ID, 이메일, 비밀번호, 결제 정보와 같은 속성을 가진 RideX 플랫폼에 등록된 사용자를 나타냅니다.
2. 드라이버 엔터티 : 운전자 ID, 차량 세부정보, 운전자 상태 등의 속성을 사용하여 RideX 플랫폼에 등록된 운전자를 나타냅니다.
3. 탑승 요청 엔터티 : 요청 ID, 픽업 위치, 목적지, 탑승 기본 설정과 같은 속성을 포함하여 사용자의 탑승 요청을 나타냅니다.
4. 라이드 엔터티 : 승차 ID, 승하차 위치, 요금, 승차 상태 등의 속성을 포함하여 승차의 단일 인스턴스를 나타냅니다.
5. 위치 값 객체 : 위도, 경도와 같은 속성을 사용하여 지리적 위치를 나타냅니다.

집계

1. 라이드 집계 : Ride Request, User, Driver 엔터티와 같은 관련 엔터티와 함께 ​​Ride Entity를 집계 루트로 구성합니다. Ride Aggregate는 라이드 요청 처리, 드라이버 할당, 라이드 상태 업데이트를 포함하여 라이드의 수명 주기를 관리하기 위한 로직을 캡슐화합니다.

저장소

1. 라이딩 저장소 : 탑승 세부 정보 검색, 탑승 상태 업데이트, 탑승 관련 데이터를 데이터베이스에 저장하는 등 탑승 관련 엔터티를 쿼리하고 저장하는 방법을 제공합니다.

서비스

1. 차량 배정 서비스 : 운전자 가용성, 픽업 위치와의 근접성, 사용자 선호도 등의 요소를 기반으로 탑승 요청에 사용 가능한 운전자를 할당하는 역할을 담당합니다.
2. 결제 서비스 : 완료된 탑승에 대한 결제 처리, 요금 계산, 결제 처리, 사용자 및 운전자 결제 정보 업데이트를 처리합니다.

도메인 이벤트

1. RideRequested이벤트 : 사용자가 탑승을 요청할 때 발생하는 이벤트를 나타내며, 탑승 요청 내역, 사용자 ID 등의 정보를 포함합니다.
2. RideAccepted이벤트 : 운전자가 탑승 요청을 수락하면 트리거되는 이벤트를 나타내며 탑승 ID, 운전자 ID, 픽업 위치 등의 정보가 포함됩니다.

예시 시나리오

1. 차량 서비스를 요청하는 사용자 : 사용자는 승차 위치, 목적지, 승차 선호 사항을 제공하여 승차를 요청합니다. RideX는 새로운 탑승 요청 엔터티를 생성하고 RideRequestedEvent를 트리거합니다.
2. 드라이버 파트너가 차량 서비스를 수락합니다. : 운전자가 RideX 플랫폼에서 탑승 요청을 수락합니다. RideX는 탑승 상태를 Accepted로 업데이트하고, 운전자를 탑승에 할당하고, RideAcceptedEvent를 트리거합니다.
3. 라이드 진행 중 : 사용자와 운전자가 탑승을 조정하며, 운전자가 픽업 위치에 도달하면 탑승 상태가 수락됨에서 진행 중으로 전환됩니다.
4. 라이딩 완료 : 목적지 도착 후 라이딩 상태가 완료로 업데이트됩니다. RideX는 요금을 계산하고 결제를 처리하며 이에 따라 사용자와 운전자의 결제 정보를 업데이트합니다.