실제 문제에 대한 복잡한 도메인
도메인 모델은 도메인 기반 디자인을 채택하는 모든 애플리케이션의 핵심입니다. ~ 안에 이벤트를 플레이하세요, 이 마음은 이렇게 이루어져 있어요 86개 엔터티 여러 집계에 분산되어 있으며, 각각은 이벤트 관리의 특정 측면을 담당합니다.
이 기사에서는 주요 집합체, 이벤트의 수명 주기, 이벤트의 역할을 분석합니다. 참가자, 가치 개체 및 플랫폼을 구성하는 하위 도메인.
이 기사에서 찾을 수 있는 내용
- 도메인의 주요 집계: 이벤트, 여행, 비용, 사용자
- 이벤트 수명주기의 상태 머신
- 참석자 역할 및 RSVP 시스템
- 가치 객체와 그 중요성
- 스마트 분할로 비용 지배
- 다단계 여정으로 구성된 여행 영역
- 추가 하위 도메인: 축제, 인벤토리, 문서, 설문지
주요 집계
도메인 이벤트를 플레이하세요 이는 각각 고유한 루트를 갖는 4개의 주요 집계로 구성됩니다. (Aggregate Root) 액세스를 제어하고 비즈니스 불변성을 유지합니다.
AGGREGATI DEL DOMINIO
EVENTO (Aggregate Root)
├── EventoId (identità)
├── Stato (macchina a stati)
├── Partecipante[]
│ ├── Ruolo (ORGANIZER, CO_ORGANIZER, ATTENDEE, VIP)
│ └── StatoRSVP (IN_ATTESA, ACCETTATO, RIFIUTATO, FORSE, SCADUTO)
├── Budget
├── Documento[]
├── Questionario[]
└── Task[]
VIAGGIO (Aggregate Root)
├── ViaggioId (identità)
├── Tappa[]
│ ├── Attività[]
│ ├── Alloggio
│ └── Trasporto
└── Budget viaggio
SPESA (Aggregate Root)
├── SpesaId (identità)
├── Categoria
├── SplitStrategy (EQUAL, PERCENTAGE, FIXED, CUSTOM)
├── Pagamento[]
└── Settlement[]
USER (Aggregate Root)
├── UserId (identità)
├── Profilo
├── Preferenze
└── Ruoli di sistema이벤트 수명주기
Play The Event의 각 이벤트는 다음에 의해 관리되는 잘 정의된 수명 주기를 거칩니다. 유효한 전환을 보장하고 불법적인 작업을 방지하는 상태 머신 현재 상태에서.
이벤트 상태
DRAFT ──────────► PUBLISHED ──────────► CONFIRMED
│ │ │
│ │ ▼
│ │ IN_PROGRESS
│ │ │
│ ▼ ▼
│ (cancellazione) EXPENSE_SPLITTING
│ │
▼ ▼
(eliminazione) COMPLETED
TRANSIZIONI VALIDE:
DRAFT → PUBLISHED (l'organizzatore pubblica l'evento)
PUBLISHED → CONFIRMED (raggiunto il quorum o conferma manuale)
CONFIRMED → IN_PROGRESS (data evento raggiunta, check-in attivo)
IN_PROGRESS → EXPENSE_SPLITTING (evento concluso, fase spese)
EXPENSE_SPLITTING → COMPLETED (tutte le spese saldate)- 초안: 이벤트가 생성되고 있습니다. 주최자만 해당 내용을 보고 편집할 수 있습니다. 초대가 불가능합니다.
- 출판: 이벤트는 초대된 참가자에게 표시됩니다. RSVP 시스템이 활성화되어 손님이 확인하거나 거절할 수 있습니다.
- 확인됨: 이벤트가 확정된 최소 참가자 수에 도달했습니다. 계획이 통합되었습니다.
- 진행 중: 이벤트가 진행 중입니다. 체크인/체크아웃이 활성화되어 있으며 실시간으로 비용을 기록할 수 있습니다.
- 비용 분할: 이벤트가 끝났습니다. 참가자 간 비용 분담 및 정산을 담당하는 단계입니다.
- 완전한: 모든 비용이 지불되었습니다. 이벤트는 보관되어 과거 통계에 사용할 수 있습니다.
참가자의 역할
각 이벤트 내에서 권한을 관리하려면 역할 시스템이 필수적입니다. 각 참가자에게는 수행할 수 있는 작업을 결정하는 역할이 있습니다.
- 조직자: 이벤트의 창시자. 수정, 취소, 참가자 관리, 예산 및 비용 관리 등을 완벽하게 제어할 수 있습니다. 이벤트당 주최자는 한 명뿐입니다.
- CO_ORGANIZER: 주최자의 협력자. 그는 참가자를 관리하고 통신문을 보내고 물류 세부 사항을 변경할 수 있지만 이벤트를 취소할 수는 없습니다.
- 기다리다: 표준 참가자. 출석 확인, 지출 기록, 채팅 참여, 설문지 작성 등을 할 수 있습니다.
- VIP: 특별한 가시성을 지닌 참가자. 제한된 장소를 관리하는 데 있어 독점적인 콘텐츠와 우선순위에 접근할 수 있습니다.
RSVP 시스템
RSVP 시스템은 다음을 포함하여 5가지 가능한 상태로 출석 확인을 관리합니다. 마감일 자동 관리.
- 보류 중: 초대장을 보냈으나 참가자가 아직 응답하지 않았습니다.
- 수락됨: 참가자가 자신의 존재를 확인했습니다.
- 거부됨: 참가자가 초대를 거부했습니다.
- 아마도: 참가자는 불확실하며 나중에 확인할 것입니다
- 만료됨: 확인 없이 응답 기한이 만료되었습니다. 시스템은 예약된 작업을 통해 이러한 전환을 자동으로 관리합니다.
값 개체
값 개체는 유효성 검사 및 동작을 캡슐화하는 도메인 구성 요소입니다. 데이터 유형에 직접 추가하여 데이터가 일관되지 않을 가능성을 제거합니다.
돈: 다중 통화 관리
가치 객체 Money 다중 통화 지원으로 금액을 관리합니다. 매
산술 연산은 통화의 호환성을 확인하고 반올림은
표준 은행 규칙(소수점 두 자리, 반올림)에 따라 처리됩니다.
이메일: 통합 검증
가치 객체 Email 시스템의 모든 이메일 주소가 구문적으로 올바른지 확인합니다.
생성 당시 유효합니다. 유효성 검사는 생성자에서 발생하므로 불가능합니다.
인스턴스의 존재 Email 형식이 잘못되었습니다.
UserId: 입력된 ID
사용하는 대신 Long o String 식별자로 시스템은
UserId, EventoId, SpesaId 및 기타 유형의 ID. 이
이벤트 ID가 예상되는 곳에 사용자 ID를 전달하는 등의 일반적인 오류를 방지합니다.
비용의 영역
가장 복잡한 기능 중 하나는 이벤트를 플레이하세요 4가지 분할 모드를 지원하는 비용 분할 시스템입니다.
MODALITA' DI SPLIT
1. EQUAL (Equa)
Spesa totale: 120 EUR / 4 partecipanti = 30 EUR ciascuno
2. PERCENTAGE (Percentuale)
Spesa totale: 200 EUR
├── Alice: 50% → 100 EUR
├── Bob: 30% → 60 EUR
└── Carol: 20% → 40 EUR
3. FIXED (Importo Fisso)
Spesa totale: 150 EUR
├── Alice: 80 EUR (fisso)
├── Bob: 50 EUR (fisso)
└── Carol: 20 EUR (fisso)
4. CUSTOM (Personalizzata)
Ogni partecipante ha un importo specifico
definito manualmente dall'organizzatore시스템이 자동으로 계산합니다. 매상 참가자들 사이에서 i를 생성합니다. 합의 최적이며 필요한 트랜잭션 수를 최소화합니다. 모든 부채를 청산합니다. 비용은 항목별로 정리되어 있습니다(식비, 교통비, 숙박비, 엔터테인먼트, 기타) 특정 이벤트나 여행지와 연관될 수 있습니다.
여행 도메인
여행 하위 도메인은 다음을 통해 복잡한 여행 일정을 관리합니다. 여러 단계, 각각 고유한 활동, 숙박 시설 및 교통 수단이 있습니다.
VIAGGIO
├── Informazioni generali
│ ├── Nome, descrizione, date
│ ├── Budget totale
│ └── Partecipanti
│
├── Tappa 1: Roma (3 giorni)
│ ├── Attività: Colosseo, Musei Vaticani, Trastevere
│ ├── Alloggio: Hotel Centro, check-in/out
│ └── Trasporto: Treno da Bari
│
├── Tappa 2: Firenze (2 giorni)
│ ├── Attività: Uffizi, Ponte Vecchio, Chianti tour
│ ├── Alloggio: B&B Oltrarno
│ └── Trasporto: Treno da Roma
│
└── Budget
├── Spese previste per tappa
├── Spese effettive registrate
└── Differenza budget추가 도메인
네 가지 주요 집합체 외에도 도메인 모델에는 여러 하위 도메인이 포함됩니다. 특화된 기능으로 플랫폼을 풍부하게 합니다.
- 축제 관리: 프로그램, 무대, 아티스트 및 라인업을 갖춘 여러 날의 이벤트 관리. 뮤직페스티벌, 멀티트랙 컨퍼런스 등 복합행사 지원
- 목록: 행사에 필요한 자재 및 자원(장비, 장식, 소모품) 추적, 수량 관리 및 관리자 배정
- 서류: 버전 관리, 공유 및 분류를 통한 문서 관리. 계약서, 허가증, 송장 및 이벤트와 관련된 모든 문서가 포함됩니다.
- 설문지: 참가자로부터 피드백, 음식 선호도, 이용 가능 시간 및 기타 데이터를 수집하기 위한 설문 조사 및 설문지를 작성 및 배포합니다.
패턴 진화: 116개 이상의 이동경로 마이그레이션
Play The Event 데이터베이스는 다음에 의해 관리됩니다. 이동경로, 그 이상으로 스키마의 전체 발전을 문서화하는 116개의 마이그레이션 스크립트. 모든 변화 데이터베이스에 대한 추적, 버전 관리 및 되돌릴 수 있습니다.
db/migration/
├── V1__create_users_table.sql
├── V2__create_events_table.sql
├── V3__create_participants_table.sql
├── V4__add_rsvp_status.sql
├── ...
├── V50__create_expense_splits.sql
├── V51__add_settlement_optimization.sql
├── ...
├── V100__create_trip_activities.sql
├── V101__add_accommodation_details.sql
├── ...
└── V116__add_questionnaire_analytics.sql왜 116개 이상의 마이그레이션이 필요합니까?
마이그레이션 수가 많다고 해서 반드시 초기 설계가 좋지 않다는 의미는 아닙니다. 오히려 접근의 결과이다. 반복 및 증분: 도메인은 요구 사항에 대한 이해와 함께 발전했으며 각 마이그레이션 도메인 모델링의 한 단계 발전을 나타냅니다. 이 접근법은 모델이 지속적으로 개선되는 DDD 원칙과 완벽하게 일치합니다. 사용자 피드백을 통해
도메인 모델 코드는 다음에서 확인할 수 있습니다. GitHub. 다음 기사에서는 JWT 보안 및 인증 시스템을 분석하여 살펴보겠습니다. 어떻게 이벤트를 플레이하세요 사용자 데이터를 보호하고 권한을 관리합니다.