1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67

# Use Case Walkthrough: Library Management System
 
## Current Entity List
- Book, BookCopy, Member, Loan, Fine, LibraryCard
 
## Use Case: Member Borrows a Book
 
| Step | Description | Entity | Operation | ✓/✗ |
|------|-------------|--------|-----------|-----|
| 1 | Member presents library card | LibraryCard | validate() | ✓ |
| 2 | Librarian scans card | LibraryCard | getMemeberId() | ✓ |
| 3 | System checks member status | Member | isActive() | ✓ |
| 4 | Member selects a book | Book | - | ✓ |
| 5 | System finds available copy | BookCopy | findAvailable() | ✓ |
| 6 | System checks loan limit | Member | canBorrow() | ✓ |
| 7 | System creates loan | Loan | create() | ✓ |
| 8 | Copy status updated | BookCopy | markBorrowed() | ✓ |
| 9 | Due date calculated | Loan | calculateDueDate() | ✓ |
| 10 | Receipt generated | ??? | ??? | ✗ MISSING |
 
## Finding: Step 10 - Receipt Generation
No entity handles receipts. Options:
A) Add Receipt entity (if receipts need to be stored/reprinted)
B) Add receipt() method to Loan (if it's just a generated view)
 
Likely decision: Add to Loan.generateReceipt() - receipts don't need independent storage.
 
 
## Use Case: Member Returns an Overdue Book
 
| Step | Description | Entity | Operation | ✓/✗ |
|------|-------------|--------|-----------|-----|
| 1 | Member returns book | BookCopy | - | ✓ |
| 2 | System identifies loan | Loan | findByBookCopy() | ✓ |
| 3 | System calculates overdue days | Loan | getOverdueDays() | ✓ |
| 4 | System calculates fine | Fine | calculate() | ✓ |
| 5 | Fine attached to member | Fine | - | ✓ |
| 6 | Member pays fine | Fine | pay() | ✓ |
| 7 | System accepts payment | ??? | ??? | ✗ MISSING |
| 8 | Loan closed | Loan | close() | ✓ |
| 9 | Copy made available | BookCopy | markAvailable() | ✓ |
 
## Finding: Step 7 - Payment Handling
Fine.pay() exists but where does payment go?
Options:
A) Add Payment entity (if payment records needed)
B) Add payment processing to Fine directly
 
Decision: Add Payment entity - we need transaction records for accounting.
 
 
## Use Case: Member Reserves an Unavailable Book
 
| Step | Description | Entity | Operation | ✓/✗ |
|------|-------------|--------|-----------|-----|
| 1 | Member searches for book | Book | search() | ✓ |
| 2 | All copies unavailable | BookCopy | none available | ✓ |
| 3 | Member requests reservation | ??? | ??? | ✗ MISSING |
| 4 | System queues request | ??? | ??? | ✗ MISSING |
| 5 | When copy returns, notify | ??? | ??? | ✗ MISSING |
 
## Finding: Entire reservation flow missing
We need:
- Reservation entity (request queue)
- Notification entity (or mechanism)
 
This was in Tier 3 but the use case requires it. Re-prioritize to Tier 2?

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105

// CRUD VALIDATION: Identifying Entity Lifecycle Issues
 
/**
 * PROBLEM 1: Entity with no Create
 * 
 * Entity: RateCard (defines pricing rules)
 * 
 * CRUD Analysis:
 * - Create: ??? (who sets up rates?)
 * - Read: System (calculates fees)
 * - Update: ??? (how do rates change?)
 * - Delete: ???
 * 
 * Issue: No create/update operations defined
 * Resolution: Add Admin-created rate management
 */
 
class RateCard {
    id: string;
    vehicleType: VehicleType;
    hourlyRate: Money;
    dailyMaxRate: Money;
    effectiveFrom: Date;  // Rates can change over time
    
    // Need Create: Admin.createRateCard()
    // Need Update: Admin.updateRateCard() or create new dated version
}
 
 
/**
 * PROBLEM 2: Entity with no Read
 * 
 * Entity: AuditLog (captures all system actions)
 * 
 * CRUD Analysis:
 * - Create: System (automatic)
 * - Read: ??? (who looks at logs?)
 * - Update: Never (immutable for audit purposes)
 * - Delete: Retention policy
 * 
 * Issue: Logs are created but never read
 * Resolution: Either add Admin.viewAuditLogs() or question if entity is needed
 */
 
// If truly never read, reconsider if it should be an entity
// Perhaps it's infrastructure logging, not domain entity
 
 
/**
 * PROBLEM 3: Entity that's "Always Mutable" - Missing State
 * 
 * Entity: Booking
 * 
 * CRUD Analysis:
 * - Create: Customer creates booking
 * - Read: Customer, Admin
 * - Update: Customer can modify, Admin can modify
 * - Delete: Customer can cancel (but is that delete?)
 * 
 * Issue: "Delete" is actually "Cancel" - a state change
 * Resolution: Bookings should have status, not be deleted
 */
 
class Booking {
    id: string;
    status: BookingStatus;  // CONFIRMED, MODIFIED, CANCELLED, COMPLETED
    
    // "Delete" is actually cancel() which changes status
    cancel(reason: string): void {
        if (this.status === BookingStatus.COMPLETED) {
            throw new Error("Cannot cancel completed booking");
        }
        this.status = BookingStatus.CANCELLED;
        this.cancellationReason = reason;
    }
}
 
 
/**
 * PROBLEM 4: Orphan Entity - No Relationships
 * 
 * Entity: VehicleType
 * 
 * CRUD Analysis shows it's used but...
 * - Created by: ???
 * - Used by: ParkingSpot, RateCard
 * - But how does VehicleType relate to Vehicle?
 * 
 * Issue: VehicleType is referenced but not linked properly
 * Resolution: Add Vehicle.type: VehicleType relationship
 */
 
class Vehicle {
    licensePlate: string;
    type: VehicleType;  // Needed for spot matching and pricing
}
 
enum VehicleType {
    MOTORCYCLE = "MOTORCYCLE",
    CAR = "CAR",
    TRUCK = "TRUCK"
}
 
// Decision: VehicleType as enum, not entity
// It doesn't need CRUD - it's a fixed set of values

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117

// RELATIONSHIP VALIDATION: Hotel Booking System
 
/**
 * Entity List: Hotel, Room, RoomType, Guest, Booking, Payment
 * 
 * Relationship Analysis:
 */
 
// Hotel → Room: One-to-Many
// A hotel has many rooms; each room belongs to one hotel
class Hotel {
    id: string;
    name: string;
    rooms: Room[];  // ✓ Can navigate to rooms
}
 
class Room {
    id: string;
    hotelId: string;  // ✓ Can navigate back to hotel
    roomNumber: string;
    typeId: string;
}
 
// Room → RoomType: Many-to-One
// Many rooms share a room type; each room has one type
class RoomType {
    id: string;
    name: string;  // "Deluxe", "Standard", "Suite"
    basePrice: Money;
    capacity: number;
    // Does RoomType need to know its rooms? Probably not.
}
 
// Guest → Booking: One-to-Many
// A guest can have multiple bookings; each booking has one guest
class Guest {
    id: string;
    name: string;
    email: string;
    // bookingIds?: string[];  // Optional: might not need reverse navigation
}
 
class Booking {
    id: string;
    guestId: string;     // ✓ References guest
    roomId: string;      // ✓ References room
    checkInDate: Date;
    checkOutDate: Date;
    status: BookingStatus;
}
 
// Booking → Room: Many-to-One (typically) or Many-to-Many?
// Question: Can one booking cover multiple rooms?
 
// VALIDATION FINDING:
// Requirement: "Guests can book multiple rooms in a single booking"
// Current design: Booking → single Room
// Issue: Cardinality is wrong!
 
// CORRECTION:
class BookingCorrected {
    id: string;
    guestId: string;
    roomBookings: RoomBooking[];  // One-to-Many with new entity
    checkInDate: Date;
    checkOutDate: Date;
}
 
// NEW ENTITY DISCOVERED: RoomBooking
// Junction entity for booking-room relationship
class RoomBooking {
    bookingId: string;
    roomId: string;
    rateApplied: Money;
    specialRequests: string[];
}
 
 
// Payment → Booking: One-to-Many or One-to-One?
// Question: Can a booking have multiple payments (deposit, final)?
 
class Payment {
    id: string;
    bookingId: string;  // ✓ References booking
    amount: Money;
    type: PaymentType;  // DEPOSIT, BALANCE, REFUND
    paidAt: Date;
}
// One booking → many payments is correct for hotel scenarios
 
 
/**
 * ORPHAN CHECK:
 * 
 * Draw connections from each entity:
 * 
 * Hotel ←→ Room ←→ RoomType (RoomType has no reference back - OK)
 * Guest ←→ Booking ←→ RoomBooking ←→ Room
 * Booking ←→ Payment
 * 
 * No orphans! Every entity connects to the core graph.
 */
 
 
/**
 * NAVIGABILITY ANALYSIS:
 * 
 * From guest, can we:
 * - Find their bookings? ✓ Query Booking by guestId
 * - Find which rooms they booked? ✓ Through Booking → RoomBooking → Room
 * - Find their payments? ✓ Through Booking → Payment
 * 
 * From room, can we:
 * - Find which bookings? ✓ Query RoomBooking by roomId
 * - Find the hotel? ✓ Room.hotelId
 * - Check if room is available? Need logic, but data is there ✓
 */

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

# Domain Expert Review: Ride-Sharing Application
 
## Entities Presented:
Rider, Driver, Ride, Vehicle, Payment, Location, Rating
 
## Review Session Notes:
 
### Terminology Issues Found:
 
DEVELOPER TERM → DOMAIN TERM
- "Ride" → Industry uses "Trip" (Uber, Lyft terminology)
- "Location" → Could be "Address" or "Coordinate" depending on use
- Decision: Rename Ride → Trip for consistency with industry
 
### Missing Concepts Identified:
 
DOMAIN EXPERT: "What about surge pricing?"
DEVELOPER: "We have flat pricing in Payment."
DOMAIN EXPERT: "Pricing varies by time, demand, and distance. It's complex."
FINDING: Need PricingRule or DynamicPricing entity
 
DOMAIN EXPERT: "What about ride types? Pool, X, XL, Black?"
DEVELOPER: "Vehicle has a 'type' attribute."
DOMAIN EXPERT: "But the ride type determines matching rules, pricing, features."
FINDING: Need RideType/ServiceLevel entity
 
### Lifecycle Clarifications:
 
DOMAIN EXPERT: "When a driver cancels, what happens?"
DEVELOPER: "Trip status becomes CANCELLED?"
DOMAIN EXPERT: "But we need to track WHO cancelled. Driver cancels = penalty. Rider cancels = maybe fee. System cancels = refund."
FINDING: Cancellation needs CancelledBy and CancellationReason
 
### Relationship Corrections:
 
DOMAIN EXPERT: "Can a rider have multiple active trips?"
DEVELOPER: "We assumed one trip at a time."
DOMAIN EXPERT: "Yes for riding, but they might schedule future trips."
FINDING: Rider → Trip is 1:Many, but only one with status ACTIVE
 
### Final Recommended Changes:
1. Rename Ride → Trip
2. Add ServiceLevel entity (X, Pool, XL, Black, etc.)
3. Add DynamicPricing or PricingEngine component
4. Enhance Trip cancellation with actor and reason
5. Add ScheduledTrip concept (future booking)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104

// COMPLETENESS CHECK: Food Delivery System
 
// Current entity list:
// Customer, Restaurant, Menu, MenuItem, Order, Driver
 
// Running through checklist:
 
// ✓ Core Domain: Restaurant, MenuItem, Order - covered
// ✓ Actors: Customer, Driver, (Restaurant as actor?) - covered
// ✓ Transactions: Order - covered
// ✗ Line Items: OrderItem - MISSING!
 
// Finding: How do we know what items are in an order?
class OrderItem {
    orderId: string;
    menuItemId: string;
    quantity: number;
    specialInstructions: string;
    priceAtOrder: Money;  // Snapshot price
}
 
// ✗ Inventory: Not needed for food delivery
// ✗ Schedules: Restaurant hours? Maybe needed.
 
class RestaurantHours {
    restaurantId: string;
    dayOfWeek: DayOfWeek;
    openTime: Time;
    closeTime: Time;
}
 
// ✓ Rules: Pricing in MenuItem - basic
// ✗ But what about: Delivery fees? Minimum order? Promotions?
 
class DeliveryZone {
    restaurantId: string;
    areaPolygon: Polygon;
    deliveryFee: Money;
    minimumOrder: Money;
    estimatedMinutes: number;
}
 
class Promotion {
    code: string;
    discountType: DiscountType;  // PERCENT, FIXED
    discountValue: number;
    validFrom: Date;
    validTo: Date;
    conditions: PromotionCondition[];
}
 
// ✓ Configuration: User preferences? Yes.
class CustomerPreferences {
    customerId: string;
    defaultAddressId: string;
    dietaryRestrictions: string[];
    pushNotificationsEnabled: boolean;
}
 
// ✗ History: Order history via Order entity - covered
// ✓ Communication: Notification needed!
 
class Notification {
    id: string;
    recipientId: string;
    recipientType: 'CUSTOMER' | 'DRIVER' | 'RESTAURANT';
    type: NotificationType;
    title: string;
    body: string;
    sentAt: Date;
    readAt: Date | null;
}
 
// ✓ Location: Address needed for delivery
 
class Address {
    id: string;
    street: string;
    city: string;
    zipCode: string;
    instructions: string;  // "Leave at door"
    coordinates: Coordinates;
}
 
// ✓ Categorization: Restaurant categories, cuisine types
 
class Category {
    id: string;
    name: string;  // "Italian", "Fast Food", "Vegetarian"
}
 
// ✗ Relationships: Following restaurants? Favorites?
 
class FavoriteRestaurant {
    customerId: string;
    restaurantId: string;
    addedAt: Date;
}
 
// SUMMARY: Completeness check revealed 7 missing entities!
// OrderItem, RestaurantHours, DeliveryZone, Promotion,
// CustomerPreferences, Notification, Address, FavoriteRestaurant
 
// Not all are Tier 1, but they're now on the radar.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150

# Movie Ticket Booking: Complete Entity Validation
 
## TECHNIQUE 1: USE CASE WALKTHROUGH
 
### Use Case: Customer Books Tickets
 
| Step | Action | Entity | Check |
|------|--------|--------|-------|
| 1 | Browse movies | Movie | ✓ |
| 2 | Select show time | Show | ✓ |
| 3 | View seat map | Screen, Seat | ✓ |
| 4 | Select seats | Seat | Need status tracking |
| 5 | Enter customer info | Customer | ✓ |
| 6 | Process payment | Payment | ✓ |
| 7 | Generate tickets | ??? | ❌ MISSING: Ticket |
| 8 | Send confirmation | ??? | ❌ MISSING: Notification |
 
FINDING: Need Ticket entity (different from Booking)
FINDING: Need Notification or Email entity
 
### Use Case: Customer Cancels Booking
 
| Step | Action | Entity | Check |
|------|--------|--------|-------|
| 1 | Find booking | Booking | ✓ |
| 2 | Check cancellation policy | ??? | ❌ MISSING: Policy |
| 3 | Calculate refund | Payment | Need refund logic |
| 4 | Process refund | Payment | Add Refund or Payment.type |
| 5 | Release seats | Seat | ✓ |
| 6 | Notify customer | Notification | Already flagged |
 
FINDING: Need CancellationPolicy or generic Policy entity
 
---
 
## TECHNIQUE 2: CRUD ANALYSIS
 
| Entity | Create | Read | Update | Delete |
|--------|--------|------|--------|--------|
| Movie | Admin | Customer, System | Admin | Admin |
| Theatre | Admin | Customer | Admin | Admin |
| Screen | Admin | System | Admin | Admin (rare) |
| Show | Admin/System | Customer | System (seats) | (never, has bookings) |
| Seat | Admin | Customer, Booking | System (status) | ❌ |
| Booking | Customer | Customer, Staff | System (cancel) | ❌ |
| Customer | Self-register | System | Customer | GDPR? |
| Payment | System | Customer, Finance | ❌ | ❌ |
| Ticket | System | Customer | ❌ | ❌ |
 
FINDING: Seat never deleted - correct, seats are fixed
FINDING: Payment never updated - correct, immutable record
FINDING: Customer delete - need soft delete for GDPR compliance
 
---
 
## TECHNIQUE 3: RELATIONSHIP VALIDATION
 
Movie (1) ←→ (M) Show: ✓ Movie has many shows
Theatre (1) ←→ (M) Screen: ✓ Theatre has many screens
Screen (1) ←→ (M) Seat: ✓ Screen has many seats
Screen (1) ←→ (M) Show: ✓ Screen has many shows
Show (1) ←→ (M) Booking: ✓ Show has many bookings
 
Booking (1) ←→ (?) Seat: How many seats per booking?
→ One booking = multiple seats (family booking)
→ Need: Booking (1) ←→ (M) Seat or BookingSeat junction
 
Customer (1) ←→ (M) Booking: ✓ Customer has many bookings
Booking (1) ←→ (1) Payment: ✓ One payment per booking
 
FINDING: Need BookingSeat junction entity for seat-booking relationship
Reason: Need to track which seats are in which booking
 
class BookingSeat {
    bookingId: string;
    seatId: string;
    showId: string;  // For quick availability check
    ticketId: string;  // Links to generated ticket
}
 
---
 
## TECHNIQUE 4: DOMAIN EXPERT REVIEW
 
Terminology:
- "Show" → Industry uses "Showtime" or "Performance" ✓ OK to use Show
- "Booking" → Also called "Reservation" in some contexts ✓ OK
 
Missing Concepts:
- "What about seat types?" → Add seatType: REGULAR, PREMIUM, VIP ✓
- "Food and beverage?" → Out of scope for MVP, note for future
- "Loyalty points?" → Out of scope, note for future
- "Group bookings?" → Handle via multiple BookingSeats ✓
 
Lifecycle Issues:
- "Show can sell out?" → Add Show.availableSeats counter
- "Double booking prevention?" → Concurrency concern, handle in logic
 
---
 
## TECHNIQUE 5: COMPLETENESS CHECKLIST
 
| Category | Needed? | Entity |
|----------|---------|--------|
| Core Domain | ✓ | Movie, Show, Seat, Booking |
| Actors | ✓ | Customer (missing: Admin?) |
| Transactions | ✓ | Booking, Payment |
| Line Items | ✓ | BookingSeat |
| Inventory | ✓ | Seat (availability) |
| Schedules | ✓ | Show (has time) |
| Rules | ⚠️ | Need: PricingRule, CancellationPolicy |
| Configuration | Optional | TheatreSettings |
| History | Optional | BookingHistory |
| Communication | ✓ | Notification |
| Location | ✓ | Theatre.address |
| Categorization | ✓ | Movie.genre |
 
---
 
## FINAL VALIDATED ENTITY LIST
 
### Tier 1 (Core):
- Movie (what's showing)
- Theatre (where)
- Screen (which auditorium)
- Show (specific performance)
- Seat (what's being booked)
- Booking (the transaction)
- Customer (who's booking)
- Payment (the money)
- Ticket (the deliverable)
- BookingSeat (seat-booking junction)
 
### Tier 2 (Supporting):
- Notification (confirmation/reminders)
- Admin (staff user)
- Refund (if cancellation supported)
 
### Tier 3 (Enhancement):
- PricingRule (dynamic pricing)
- CancellationPolicy (rules)
- Promotion (discounts)
 
### Discovered Issues Fixed:
1. Added Ticket entity (separate from Booking)
2. Added BookingSeat junction entity
3. Added Notification entity
4. Noted need for Policy/Rules entities
5. Added seatType to Seat
6. Confirmed soft delete for Customer