実際の問題の複雑な領域
ドメイン モデルは、ドメイン駆動設計を採用するアプリケーションの中心です。 で イベントをプレイする、 この心はでできています 86 エンティティ 複数の集合体に分散され、 それぞれがイベント管理の特定の側面を担当します。
この記事では、主な集計、イベントのライフサイクル、イベントの役割を分析します。 プラットフォームを構成する参加者、値オブジェクト、およびサブドメイン。
この記事でわかること
- ドメインの主な集計: イベント、旅行、経費、ユーザー
- イベントライフサイクルのステートマシン
- 出席者の役割と出欠確認システム
- 価値オブジェクトとその重要性
- 賢い分割による経費の支配
- 多段階の旅程を伴う旅行の領域
- 追加のサブドメイン: フェスティバル、目録、ドキュメント、アンケート
主要な集合体
のドメイン イベントをプレイする 4 つの主要な集合体を中心に構成されており、それぞれに独自のルートがあります。 (集約ルート) アクセスを制御し、ビジネスの不変条件を維持します。
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 システムがアクティブになっており、ゲストは確認または拒否できます。
- 確認済み： イベントは確認された最小参加者数に達しました。計画が一本化されます。
- 進行中： イベントが進行中です。チェックイン/チェックアウトは有効であり、経費はリアルタイムで記録できます。
- EXPENSE_SPLITTING: イベントは終わりました。これは、参加者間での費用の分割と精算に特化したフェーズです。
- 完了: すべての費用は支払われています。イベントはアーカイブされ、履歴統計に利用できます。
参加者の役割
ロール システムは、各イベント内の権限を管理するために不可欠です。 各参加者には、実行できるアクションを決定する役割があります。
- 主催者: イベントの作成者。変更、キャンセル、参加者の管理、予算と経費の管理を完全に制御できます。主催者はイベントごとに 1 人だけです。
- 共同主催者: 主催者の協力者。彼は参加者の管理、通信の送信、ロジスティックの詳細の変更を行うことができますが、イベントをキャンセルすることはできません。
- 待って： 標準参加者。出欠の確認、経費の記録、チャットへの参加、アンケートへの記入などが行えます。
- VIP: 特別な可視性を持つ参加者。独占的なコンテンツにアクセスし、限られた場所を優先的に管理できます。
RSVP システム
RSVP システムは、次の 5 つのステータスで出席確認を管理します。 期限の自動管理。
- 保留中： 招待状は送信されましたが、参加者はまだ応答していません
- 受け入れられました: 参加者は自分の存在を確認した
- 拒否した： 参加者は招待を拒否しました
- 多分： 参加者は不明なので後で確認します
- 期限切れ： 確認がないまま回答期限が過ぎてしまいました。システムは、スケジュールされたジョブを通じてこの移行を自動的に管理します。
値オブジェクト
値オブジェクトは、検証と動作をカプセル化するドメイン構成要素です。 データ型に直接入力することで、データの不整合の可能性を排除します。
お金: 複数通貨管理
値オブジェクト Money 多通貨サポートで金額を管理します。毎
算術演算は通貨の互換性をチェックし、丸めは
標準の銀行ルール (小数点以下 2 桁、HALF_UP 四捨五入) に従って処理されます。
電子メール: 統合された検証
値オブジェクト Email システム内のすべての電子メール アドレスが構文的に正しいことを保証します
作成時に有効です。検証はコンストラクター内で行われるため、検証は不可能になります
インスタンスの存在 Email 無効な形式です。
UserId: 型指定された ID
使用する代わりに Long o String システムは識別子として使用します
UserId, EventoId, SpesaId およびその他の入力された ID。これ
イベント ID が必要な場所にユーザー ID を渡すなどの一般的なエラーを防ぎます。
経費の領域
最も複雑な機能の 1 つは、 イベントをプレイする は、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が生成されます 決済 最適化され、必要なトランザクション数が最小限に抑えられます。 すべての借金を帳消しにする。費用はカテゴリー（食費、交通費、宿泊費、 エンターテイメント、その他）、特定のイベントや旅行の目的地に関連付けることができます。
旅行の領域
travel サブドメインは、複雑な旅程を管理します。 複数の段階、 それぞれに独自のアクティビティ、宿泊施設、交通手段があります。
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追加のドメイン
4 つの主要な集合体に加えて、ドメイン モデルにはいくつかのサブドメインが含まれています 特殊な機能でプラットフォームを強化します。
- フェスティバル運営: プログラム、ステージ、アーティスト、ラインナップを含む複数日にわたるイベントの管理。音楽フェスティバルやマルチトラックカンファレンスなどの複雑なイベントをサポート
- 在庫： イベントに必要な資材とリソース（設備、装飾、消耗品）の追跡、数量管理とマネージャーへの割り当て
- 書類: バージョン管理、共有、分類によるドキュメント管理。契約書、許可証、請求書、イベントに関連するあらゆる文書が含まれます
- アンケート: 参加者からフィードバック、食べ物の好み、利用可能な時間、その他のデータを収集するためのアンケートやアンケートを作成および配布する
パターンの進化: 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 のセキュリティと認証システムを分析し、詳しく見ていきます。 どうやって イベントをプレイする ユーザーデータを保護し、権限を管理します。