Identifying Core Entities

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

# Parking Lot System - Requirements
 
## Core Requirements
1. The **parking lot** has multiple **floors**.
2. Each **floor** has multiple **parking spots** of different types.
3. **Parking spots** can be SMALL, MEDIUM, or LARGE.
4. **Vehicles** can be **motorcycles**, **cars**, or **trucks**.
5. A **vehicle** can only park in a compatible **spot**.
6. When a **vehicle** enters, a **ticket** is generated.
7. The **ticket** records the **entry time** and **spot** assignment.
8. When a **vehicle** exits, the **fee** is calculated based on duration.
9. **Payment** can be made via cash, credit card, or mobile payment.
10. The **system** should track **occupancy** per floor.
11. **Admins** can add or remove floors and spots.
12. **Display boards** show available spots per floor.
 
## Additional Requirements
13. VIP **customers** get reserved **spots** near entrances.
14. Electric **vehicles** can use charging **stations**.
15. The **rate** varies by vehicle type and duration.

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

// Validation example: Applying criteria to ParkingSpot
 
/**
 * Candidate: ParkingSpot
 * 
 * ✅ Identity test: Yes - each spot has a unique identifier (e.g., "A-101")
 * ✅ State test: Yes - available, occupied, reserved, out-of-service
 * ✅ Behavior test: Yes - canFit(vehicle), assign(ticket), release()
 * ✅ Relationship test: Yes - belongs to Floor, assigned to Vehicle via Ticket
 * ✅ Multiplicity test: Yes - parking lot has hundreds of spots
 * ✅ Persistence test: Yes - spot configuration stored in database
 * ✅ Domain expert test: Yes - parking attendants understand "spot"
 * 
 * Result: CONFIRMED as entity
 */
class ParkingSpot {
    id: string;
    spotNumber: string;
    floor: Floor;
    size: SpotSize;
    status: SpotStatus;
    
    canFit(vehicle: Vehicle): boolean { /* ... */ }
    assign(ticket: Ticket): void { /* ... */ }
    release(): void { /* ... */ }
}
 
/**
 * Candidate: ChargingStation
 * 
 * ✅ Identity test: Yes - each station has a unique ID
 * ✅ State test: Yes - available, in-use, out-of-order
 * ✅ Behavior test: Yes - startCharging(), stopCharging()
 * ⚠️  Relationship test: Related to spot? Is it a spot type or spot feature?
 * ✅ Multiplicity test: Yes - multiple stations in the lot
 * ✅ Persistence test: Yes - track station usage
 * ✅ Domain expert test: Yes - recognized concept
 * 
 * Design decision needed: Is ChargingStation a type of ParkingSpot,
 * or a separate entity associated with certain spots?
 * 
 * Option A: ChargingSpot extends ParkingSpot
 * Option B: ChargingStation is associated with ParkingSpot
 */
 
/**
 * Candidate: VIPCustomer vs Customer
 * 
 * Question: Are these separate entities or one entity with a type attribute?
 * 
 * If VIP has significantly different behavior:
 *   → Separate class or subclass
 * 
 * If VIP is just a flag affecting discounts:
 *   → Single Customer class with membershipType attribute
 * 
 * Apply YAGNI: Start simple, refactor if needed
 */

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

# Library Management System - Requirements
 
1. The library contains a large collection of books and media items.
2. Members can borrow books for a loan period of up to 14 days.
3. Each book has an ISBN, title, author, and publication year.
4. The library has multiple copies of popular books.
5. Members must have a valid library card to borrow items.
6. Librarians can add new books, register members, and manage fines.
7. Books can be reserved if all copies are currently on loan.
8. Overdue books incur a daily fine.
9. The catalog can be searched by title, author, subject, or ISBN.
10. Members can renew loans online if no one has reserved the book.
11. The library has different membership tiers: Basic, Premium, Research.
12. Premium members can borrow more items and have longer loan periods.
13. Notifications are sent for due dates and available reservations.

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

// Analyzing noun phrases from requirements
 
/**
 * "parking spot" → Single entity with compound name
 * The phrase represents one indivisible concept.
 * 
 * Design: ParkingSpot class
 */
class ParkingSpot { }
 
/**
 * "book author" → Relationship between entities
 * Both "book" and "author" are entities; the phrase describes their relationship.
 * 
 * Design: Book has Author (composition or reference)
 */
class Book {
    author: Author;  // or authors: Author[]
}
class Author { }
 
/**
 * "loan period" → Attribute of entity
 * "loan" is the entity; "period" qualifies a property of loans.
 * 
 * Design: Loan has period attribute
 */
class Loan {
    period: number;  // in days
    startDate: Date;
    endDate: Date;
}
 
/**
 * "VIP customer" → Qualified subset of entity
 * "VIP" qualifies "customer" — could be a subclass or a type.
 * 
 * Design Option 1: Inheritance
 */
class Customer { }
class VIPCustomer extends Customer { }
 
/**
 * Design Option 2: Type attribute (often preferred)
 */
enum MembershipTier { BASIC, PREMIUM, VIP }
class Customer {
    tier: MembershipTier;
}
 
/**
 * "credit card payment" → Strategy or type
 * Suggests different payment methods with different behavior.
 * 
 * Design: Strategy pattern
 */
interface PaymentMethod {
    processPayment(amount: Money): PaymentResult;
}
class CreditCardPayment implements PaymentMethod { }
class CashPayment implements PaymentMethod { }
class MobilePayment implements PaymentMethod { }

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

// PITFALL: Over-extraction
// ❌ Every noun as a class creates noise
class Title { value: string; }
class Author { value: string; }
class PublicationYear { value: number; }
class ISBN { value: string; }
 
// ✅ Appropriate: These are attributes of Book
class Book {
    title: string;
    author: string;
    publicationYear: number;
    isbn: string;
}
 
// PITFALL: Missing implicit entities
// Requirement: "The system notifies users when their order ships"
// The verb "notifies" implies a Notification entity - don't miss it!
 
// ❌ Missing notification concept
class Order {
    ship(): void {
        // Somehow notifies user... no Notification entity
    }
}
 
// ✅ Recognizing the implicit entity
class Notification {
    recipient: User;
    type: NotificationType;
    sentAt: Date;
    read: boolean;
}
 
class Order {
    ship(): Notification {
        // Creates and sends notification
        return new Notification(this.customer, NotificationType.ORDER_SHIPPED);
    }
}
 
// PITFALL: Implementation bleed
// ❌ Technical terms creeping into domain model
class DatabaseConnection { }
class HTTPRequest { }
class JSONPayload { }
class CacheManager { }
 
// These are infrastructure concerns, not domain entities.
// The domain model for an e-commerce system doesn't include "database"
// even though the system uses one.
 
// ✅ Domain entities only
class Product { }
class Order { }
class Customer { }
class Payment { }