Uber/Ola 様の乗車予約システムの設計（LLD と UML のアプローチ）

低レベル設計（Low-Level Design）を実践した際、UML 図を描くことに直接飛び込むと、カオスで混乱した設計になりやすいことに気づきました。 そこで、私は段階的なアプローチを採用しました：システムをコンポーネントに分解し、フローを理解し、最後にそれを整った UML 図に翻訳する。 簡易的な Uber/Ola 様のシステムの設計をどのように進めたかをご紹介します。 **乗車予約システムの設計** - 利用者を「出発地」から「目的地」へ移動させます - シンプルに始めましょう。主なアクターはいったい誰ですか？ - Rider（乗客）→ 乗車予約を依頼します - これがシステムの基盤です。他のすべてはそれらを中心に構築されます。 初期設計を過剰に複雑化しないように、いくつかの仮定を立てました： - 各ドライバーは 1 つの車両を有する - 👉 これはスコープを絞り込み、完全性よりも正確性に焦点を当てる手助けになります。 クラスに飛び込むのではなく、まずはクライアント側からのエンドツーエンドのフローを定義しました： Rider がソース、目的地、rideType を入力する ↓ RideBookingSystem がリクエストを受信する ↓ RideService がフローを統括する ↓ RideFactory → Bike / Auto / Cab を作成する ↓ StrategyMgr → 料金とマッチング戦略を選択する ↓ ドライバーがマッチされる ↓ 料金が計算される ↓ 乗車予約が作成される 👉 このステップが極めて重要であり、クラスの設計に直接影響を与えます。 - Trip（乗車予約）→ 乗車を表します - TripMgr → 乗車予約のライフサイクルを管理します - 👉 これらはデータとオペレーションを統括する中央処理として機能します。 良い UML を作成する鍵は関係性の理解です。 - Aggregation（緩く結合） - 👉 これらのオブジェクトは互いに独立して存在できます。 - Composition（密に結合） - 👉 乗車予約のライフサイクルは TripMgr によって制御されます。 システムを拡張可能にするための手法： - 🔹 シングルトンパターン - 用途: - TripMgr - RiderMgr - DriverMgr - 👉 これらのクラスがデータベースと対話するため、単一の真実の源泉を保証します。 - 🔹 ストラーテジーパターン - 用途: - 料金算出戦略 - ドライバーマッチング戦略 - PricingStrategy → Default / RatingBased - DriverMatchingStrategy → LeastTimeBased - 👉 これはロジックのハードコーディングを避け、簡単に拡張可能にします。 - 🔹 ファクトリパターン（乗車選択） - RideFactory → BikeRide / AutoRide / CabRide - フロー: - ユーザーがライドタイプを選択 - RideService が RideFactory に作成を委任 - ファクトリが適切なライドタイプオブジェクトを返す 参考文献のため、大まかな UML 図を添付しました。 この演習は私に: - コードを書く前にフローで考えるよう助くれました - 学び続ける中で、他の人々がどのようにこの課題をアプローチするか聞きたいです🙌

When I started practicing Low-Level Design, I realized that jumping directly into drawing UML diagrams often leads to messy, confusing designs. So instead, I followed a step-by-step approach—breaking the system into components, understanding flow, and then translating that into a clean UML. Here’s how I approached designing a simplified Uber/Ola system. Design a ride-booking system that can: Create a trip (source → destination) Start simple. Who are the main actors? Rider → requests a trip These are the foundation of the system. Everything else builds around them. To avoid overcomplicating early design, I made a few assumptions: Each driver has one vehicle 👉 This helps narrow scope and focus on correctness over completeness. Instead of jumping into classes, I first defined the end-to-end flow from client side: Rider enters source, destination, rideType ↓ RideBookingSystem receives request ↓ RideService orchestrates flow ↓ RideFactory → creates Bike / Auto / Cab ↓ StrategyMgr → selects pricing & matching strategy ↓ Driver is matched ↓ Price is calculated ↓ Trip is created 👉 This step is crucial—it directly drives your class design. Trip → represents a ride TripMgr → manages trip lifecycle 👉 These act as centralized handlers for data and operations. Understanding relationships is key to a good UML. Aggregation (loosely coupled) 👉 These objects can exist independently. Composition (tightly coupled) 👉 Trip lifecycle is controlled by TripMgr. To make the system extensible: 🔹 Singleton Pattern Used for: TripMgr RiderMgr DriverMgr 👉 Ensures a single source of truth as these classes will be interacting with database. 🔹 Strategy Pattern Used for: Pricing Strategy Driver Matching Strategy PricingStrategy → Default / RatingBased DriverMatchingStrategy → LeastTimeBased 👉 This avoids hardcoding logic and allows easy extension. 🔹 Factory Pattern (Ride Selection) RideFactory → BikeRide / AutoRide / CabRide Flow: User selects ride type RideService delegates creation to RideFactory Factory returns appropriate ride type object Have attached a rough UML diagram for reference This exercise helped me: Think in terms of flow before code Still learning—would love to hear how others approach this problem 🙌