Assign responsibilities

Overview

Step 3: assign behavior to entities. Use the Information Expert principle (give a responsibility to the class that has the data needed), keep each class cohesive (SRP), and make services thin orchestrators for use cases that span several entities. The goal is a rich domain model where rules live next to the data they protect.

For each use case step, ask 'who knows?' and 'who should enforce this rule?'. Show knows its seats, so Show decides whether seats can be held. Hold knows its expiry, so it answers isExpired(). BookingService coordinates holding, paying, and confirming but does not contain seat rules.

When to use it

• After listing entities, before coding.
• When a service class is growing too large.
• When the same rule appears in multiple places.

Where it shows up in interviews

Where it is used in real software

Key terms

Information Expert

Assign to the class with the needed information.

Creator

The class that contains or aggregates B should create B.

Controller

A service handling a use case's system events.

Cohesion

How focused a class's responsibilities are.

How it works, step by step

1. 1
   List use case steps

   hold seats, compute price, charge, confirm.

2. 2
   For each step ask 'who knows?'

   Show knows seats; PricingStrategy knows prices.

3. 3
   Assign rule enforcement to the owner

   Show.hold() rejects unavailable seats.

4. 4
   Keep orchestration in services

   BookingService calls Show, Payment, Hold.

5. 5
   Check cohesion

   Each class's methods relate to one concept.

Responsibility assignment

Movie ticket use cases

BookingService stays short because each rule lives with its expert.

Implementation

1class Hold {2  constructor(readonly id: string, readonly showId: string, readonly userId: string, readonly seatIds: string[], readonly expiresAt: number) {}3  isExpired(now: number) { return now >= this.expiresAt; }                 // expert: knows its expiry4}5 6class Show {7  private status = new Map<string, "available" | "held" | "booked">();8  constructor(readonly id: string, seatIds: string[]) { seatIds.forEach((s) => this.status.set(s, "available")); }9 10  hold(seatIds: string[]) {                                                 // expert: owns seat state11    if (!seatIds.every((s) => this.status.get(s) === "available")) throw new Error("Seat unavailable");12    seatIds.forEach((s) => this.status.set(s, "held"));13  }14  book(seatIds: string[]) {15    if (!seatIds.every((s) => this.status.get(s) === "held")) throw new Error("Seats not held");16    seatIds.forEach((s) => this.status.set(s, "booked"));17  }18  release(seatIds: string[]) { seatIds.forEach((s) => this.status.get(s) === "held" && this.status.set(s, "available")); }19}20 21class BookingService {                                                      // controller: orchestrates only22  constructor(private shows: Map<string, Show>, private pay: (u: string, c: number) => Promise<boolean>, private now = () => Date.now()) {}23  async confirm(hold: Hold, amountCents: number) {24    const show = this.shows.get(hold.showId)!;25    if (hold.isExpired(this.now())) { show.release(hold.seatIds); throw new Error("Hold expired"); }26    if (!(await this.pay(hold.userId, amountCents))) { show.release(hold.seatIds); throw new Error("Payment failed"); }27    show.book(hold.seatIds);28  }29}

Complexity and performance

Trade-offs

Variants and related techniques

Common mistakes

• Anemic entities with all rules in services.

  Fix: Move rules to the entity that owns the data.

• God service.

  Fix: Split by use case and delegate to entities and policies.

Interview questions

Practice problems