イベントをプレイするための概要
イベントをプレイする イベント管理を簡素化するという具体的なニーズから生まれました。誰が企画したのか パーティー、グループ旅行、企業イベントなどでは、調整がどれほど混乱するかがわかります。 Excel シート、WhatsApp グループなどの断片化されたツールを使用して、ゲスト、経費、予算、ロジスティクスを管理します。 そして散らばったメモ。
このプロジェクトは、1 つに統合された完全なイベント管理プラットフォームを表します。 イベントの企画から費用の分担まで、エコシステムに必要なものすべてを、 旅行計画から人工知能によるデータ分析まで。
このシリーズで学ぶこと
- 実際のプロジェクトに適用されたヘキサゴナル アーキテクチャと DDD/CQRS パターン
- 86 個のエンティティと複数の集計を含む複雑なドメインをモデル化する方法
- HttpOnly Cookie と RBAC を使用した JWT ベースのセキュリティ システム
- ステートマシンと参加ロールによる高度なイベント管理
- 4つの分割モードを備えたインテリジェントな経費分割システム
- 複数段階の旅程による旅行計画
- 支払いのための Stripe との統合
- Python FastAPI と機械学習を使用した分析モジュール
- 21 か国語での国際化
- 実稼働環境でのテストおよび展開戦略
解決できる問題
友人とのディナーであれ、企業のカンファレンスであれ、イベントを企画するには一連の作業が必要です。 繰り返し発生する課題の管理: ゲストリストと出席確認の管理、追跡 予算と経費の計算、旅行と物流の調整、コストの均等配分 参加者間で共有し、全員にリアルタイムで最新情報を提供します。
市場の既存のソリューションは通常、1 つの共有経費アプリと別のアプリというように断片化されています。 招待状、予算のスプレッドシート、すべてを調整するための無数のチャット メッセージ。 イベントをプレイする は、これらすべての機能を単一の一貫したプラットフォームに統合します。
テクノロジースタック
このプラットフォームは最新の堅牢なテクノロジー スタックに基づいており、次のことを保証するように設計されています。 拡張性、保守性、および高いパフォーマンス。
バックエンド: Spring Boot 3.4.5 + Java 21
システムの中心となるのは、以下で構築されたバックエンドです。 スプリングブート 3.4.5 e ジャワ21、レコードやパターンなどの言語の最新機能を活用 マッチングスレッドと仮想スレッド。バックエンドは分離されたヘキサゴナル アーキテクチャを実装します。 ドメイン、アプリケーション、インフラストラクチャ、インターフェイスの間で厳密に管理されます。
フロントエンド: Angular 19
ユーザーインターフェースは以下で作られています 角度 19、スタンドアロンを使用する コンポーネント、反応状態管理用の信号、サポート付きの一貫した設計システム レスポンシブデザインの完成です。
データベース: MySQL
リレーショナルデータベース MySQL 以上のデータ永続性を管理します 116 フライウェイの移行 これは、時間の経過に伴うスキーム全体の進化を文書化します。
分析: Python FastAPI
専用のマイクロサービス FastAPI を使用した Python 高度な分析を扱い、 イベント管理を最適化するための機械学習ベースの洞察を提供します。
主な特徴
イベントをプレイする は、組織のあらゆる側面をカバーするように設計された豊富な機能セットを提供します。
- 完全なイベント管理: 作成、公開、異なる役割 (主催者、共催者、参加者、VIP) を持つ参加者の管理、およびイベント ライフ サイクルのステート マシン
- インテリジェントな経費の内訳: 4つの分割モード（フェア、パーセンテージ、定額、カスタム）、複数通貨サポートおよび自動残高計算
- 旅行の計画: アクティビティ、宿泊施設、移動手段を含む、予算とスケジュールを備えた複数段階の旅程
- AI による分析: 過去のデータに基づいた出席者数の予測、コスト分析、予算の最適化提案
- アジャイルツール: スプリント、ストーリーポイント、作業組織用の統合カンバンボードを使用したタスク管理
- リアルタイムのコラボレーション: WebSocket 通知、参加者リストのライブ更新、統合チャット
高レベルのアーキテクチャ
Play The Event のアーキテクチャは次の原則に従っています。 ドメイン駆動設計 (DDD) と組み合わせて六角形の建築 そしてそのパターン CQRS (コマンドクエリ責任分離)。
PLAY THE EVENT - ARCHITETTURA
1. DOMAIN LAYER (Nucleo)
├── Entità di dominio (86 entità)
├── Value Objects (Money, Email, UserId)
├── Aggregate Roots
└── Domain Events
2. APPLICATION LAYER
├── Command Handlers (scrittura)
├── Query Handlers (lettura)
└── Application Services
3. INFRASTRUCTURE LAYER
├── JPA Repositories
├── Security (JWT, OAuth2)
├── Stripe Integration
├── Email Service
└── WebSocket Adapters
4. INTERFACES LAYER
├── 53 REST Controllers
├── DTOs e MapStruct Mappers
└── 100+ API Endpointsこの分離により、ドメインが純粋でフレームワークから独立したままになることが保証されます。 システムのテスト、保守性、および時間の経過に伴う進化を促進します。
プロジェクト番号
プラットフォームの複雑さと成熟度を理解するには、次のとおりです。 いくつかの重要な数字:
- 86 のドメイン エンティティ イベント、参加者、経費、旅費、書類、アンケートなどをモデル化します。
- 53 REST コントローラー プラットフォームの API を公開する
- 100 以上の API エンドポイント 文書化されテストされた
- 21言語をサポート 完全な国際化システムのおかげで
- 116 以上のデータベース移行 スキームの制御された進化のために Flyway で管理
- 4つの経費分割モード あらゆるコスト分担シナリオをカバーする
- 6つのイベントライフサイクル状態 ステートマシン経由で管理
プロジェクトのソース コードは GitHub プロファイルで入手できます github.com/fedcal.
シリーズの構成
この一連の技術記事では、あらゆる側面を詳しく調査します。 イベントをプレイする、 アーキテクチャから展開まで。それぞれの項目の目的は、 同様のパターンを実装したい人のための実用的なガイドとドキュメントの両方 採用されたデザイン選択の詳細。
次の記事では、ヘキサゴナル アーキテクチャと DDD パターンを詳細に分析します。 86 個のエンティティを含むドメイン モデル、JWT セキュリティ システム、管理 イベントや参加者など。各記事にはコード例が含まれます 現実世界、アーキテクチャ図、開発中に学んだ教訓。
シリーズをフォローするための前提条件
- Java と Spring Boot フレームワークの基本的な知識
- REST API とリレーショナル データベースの概念に精通している
- SOLID の原則と基本的な設計パターンの理解
- ソフトウェア アーキテクチャとドメイン駆動設計への関心