priyanka-pitla277/ridewise

1. Overall shape

RideWise is a single-process, console-driven Java application with an in-memory backend. There is no external database or web layer in this repo; the architecture is centered on a command-line Main entrypoint that orchestrates domain services.

2. Entry and interaction layer

com.airtribe.ridewise.Main is the user-facing shell. It exposes the CLI menu for:

registering riders/drivers, listing available drivers, requesting rides, completing rides, and viewing rides. This layer should be drawn as the top boundary that calls into services only.

3. Service layer as the business boundary

The core workflow lives in:

- RiderService

- DriverService

- RideService

These classes coordinate validation, entity creation, state transitions, and repository access. They are the main application boundary between the CLI and domain/persistence concerns.

4. Domain model

The primary entities are:

- Rider

- Driver

- Ride

- Location

- FareReceipt

These represent the ride-sharing domain state: users, vehicle/availability, trip lifecycle, coordinates, and fare output. Ride is the central aggregate tying rider, driver, locations, status, and pricing together.

5. Repositories are in-memory persistence

Persistence is abstracted via repository interfaces and implementations:

- DriverRepository / DriverRepositoryImpl

- RiderRepository / RiderRepositoryImpl

- LocationRegistry

This is not database-backed; state is likely held in memory using concurrent collections. LocationRegistry is a supporting repository-like component used to track or resolve location-related data for matching.

6. Strategy-based ride matching

Driver allocation is pluggable through RideMatchingStrategy with implementations:

- NearestDriverStrategy

- LeastActiveDriverStrategy

RideService depends on the strategy interface rather than a concrete algorithm, so matching behavior can be swapped without changing ride orchestration. This is the main variability point in the system.

7. Strategy-based fare calculation

Pricing is also pluggable through FareStrategy with implementations:

- DefaultFareStrategy

- PeakHourFareStrategy

Fare computation is separated from ride lifecycle logic, allowing standard pricing and surge/peak pricing to be selected independently. FareReceipt is likely the output artifact of this pricing path.

8. Ride lifecycle flow

The main business flow is:

1. register rider / driver

2. request ride

3. choose driver via matching strategy

4. compute fare via fare strategy

5. create/update Ride

6. mark ride completed and release driver availability

RideStatus captures lifecycle state transitions, and NoDriverAvailableException handles the failure path when matching cannot find a driver.

9. Shared domain rules and configuration

Supporting pieces include:

- VehicleType and RideStatus enums for constrained domain values

- Constants for shared configuration

- IdGenerator for unique identifiers

The readme emphasizes thread safety; the architecture likely relies on atomic ID generation and concurrent maps to keep the in-memory state safe under concurrent access.

10. Testing and documentation boundary

Tests are manual, not a full automated suite:

- repository manual test for DriverRepositoryImpl

- service manual tests for rider, driver, and ride services

The docs/ folder contains class model, object relationships, requirements, and SOLID reflection, which are useful for diagramming the object graph and service/repository responsibilities.

11. What to show in an architecture diagram

A clear diagram should show:

- Main at the top

- services in the middle

- repositories and strategy interfaces below

- domain models as shared objects between them

The most important dependency arrows are: Main -> Services, RideService -> Strategy interfaces, Services -> Repositories, and Repositories <-> Domain models. The system is intentionally layered and interface-driven, with in-memory state at the bottom.