Tell, Don't Ask - Learning Module

Loading content...

0/246

Tell, Don't Ask Examples

Principles in Practice

Understanding Tell, Don't Ask conceptually is one thing. Applying it instinctively in the heat of development is another. This page bridges that gap with extensive real-world examples that demonstrate how TDA transforms code from interrogative proceduralism to true object-oriented collaboration.

We'll examine scenarios across multiple domains, each showing the 'ask-heavy' approach alongside the 'tell-oriented' transformation. By seeing the same pattern repeat across different contexts, you'll develop the pattern recognition that makes TDA second nature.

What You Will Learn

By the end of this page, you will have seen TDA applied to e-commerce systems, banking operations, game development, notification systems, and more. Each example demonstrates the transformation from procedural to object-oriented thinking, highlighting the specific improvements in encapsulation, maintainability, and expressiveness.

E-Commerce: Shopping Cart Operations

Shopping carts are ubiquitous in e-commerce systems. Let's examine how TDA transforms cart operations from procedural to object-oriented.

cart-ask-heavy.ts
TypeScript
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
// Ask-Heavy Anti-Pattern: Procedural cart processing
class CartCheckoutService {
    checkout(cart: Cart): Order {
        // Asking cart for its data
        const items = cart.getItems();
        const customerId = cart.getCustomerId();
        const promoCode = cart.getPromoCode();
        
        // Performing calculations externally
        let subtotal = 0;
        for (const item of items) {
            const price = item.getPrice();
            const quantity = item.getQuantity();
            subtotal += price * quantity;
        }
        
        // More external logic based on cart state
        let discount = 0;
        if (promoCode) {
            const promo = this.promoService.getPromo(promoCode);
            if (promo.getType() === 'percentage') {
                discount = subtotal * promo.getValue() / 100;
            } else if (promo.getType() === 'fixed') {
                discount = promo.getValue();
            }
        }
        
        // Checking customer status externally
        const customer = this.customerService.getCustomer(customerId);
        if (customer.getMembershipLevel() === 'premium') {
            discount += subtotal * 0.05; // Extra 5% for premium
        }
        
        const total = subtotal - discount;
        
        // Validating externally
        if (items.length === 0) {
            throw new Error('Cart is empty');
        }
        if (total < 0) {
            throw new Error('Invalid total');
        }
        
        // Creating order with extracted data
        const order = new Order();
        order.setCustomerId(customerId);
        order.setItems(items);
        order.setSubtotal(subtotal);
        order.setDiscount(discount);
        order.setTotal(total);
        
        // Clearing cart externally
        cart.setItems([]);
        cart.setPromoCode(null);
        
        return order;
    }
}

Problems with this approach:

Cart is a passive data container
Business logic (pricing, discounts) scattered in service
Validation happens externally, after state extraction
Duplicated calculations across services
Cart state mutated externally (broken encapsulation)
Testing requires mocking many getters

Banking: Account Transfers

Banking operations are classic examples where TDA dramatically improves code quality and safety. Let's examine money transfers.

bank-ask-heavy.ts
TypeScript
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
// Ask-Heavy Anti-Pattern: External manipulation
class TransferService {
    transfer(
        sourceId: string, 
        targetId: string, 
        amount: number
    ): TransferResult {
        const source = this.accountRepo.find(sourceId);
        const target = this.accountRepo.find(targetId);
        
        // Asking accounts for their state
        const sourceBalance = source.getBalance();
        const sourceStatus = source.getStatus();
        const sourceLimit = source.getDailyLimit();
        const todaysTransfers = source.getTodaysTransferTotal();
        
        const targetStatus = target.getStatus();
        const targetType = target.getType();
        
        // External validation using extracted state
        if (sourceStatus !== 'active') {
            throw new Error('Source account inactive');
        }
        if (targetStatus !== 'active') {
            throw new Error('Target account inactive');
        }
        if (sourceBalance < amount) {
            throw new Error('Insufficient funds');
        }
        if (todaysTransfers + amount > sourceLimit) {
            throw new Error('Daily limit exceeded');
        }
        if (targetType === 'closed' || targetType === 'frozen') {
            throw new Error('Cannot transfer to this account');
        }
        
        // External state manipulation
        source.setBalance(sourceBalance - amount);
        source.setTodaysTransferTotal(todaysTransfers + amount);
        target.setBalance(target.getBalance() + amount);
        
        // External record keeping
        source.addTransaction(new Transaction('debit', amount, targetId));
        target.addTransaction(new Transaction('credit', amount, sourceId));
        
        return new TransferResult(true, source.getBalance());
    }
}

Problems:

Business rules (limits, status checks) extracted from accounts
Account state manipulated externally—dangerous!
Transaction records created externally
Same validation logic would be duplicated for withdrawals, payments
Race condition risks with external get/set patterns

Domain Events

In real banking systems, accounts might also raise domain events like TransferCompleted that other parts of the system react to (notifications, audit logs). These events are raised internally by the account, not created externally—another form of 'tell' over 'ask'.

Gaming: Character Combat

Game development offers rich examples where TDA keeps combat systems maintainable. Let's examine character-vs-character combat.

game-ask-heavy.ts
TypeScript
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
// Ask-Heavy Anti-Pattern: External combat logic
class CombatEngine {
    attack(attacker: Character, defender: Character): CombatResult {
        // Asking characters for all their stats
        const attackPower = attacker.getStrength() + attacker.getWeaponDamage();
        const attackerLevel = attacker.getLevel();
        const attackerBuffs = attacker.getActiveBuffs();
        
        const defenderArmor = defender.getArmor();
        const defenderLevel = defender.getLevel();
        const defenderHealth = defender.getHealth();
        const defenderShield = defender.getShield();
        const defenderDebuffs = defender.getActiveDebuffs();
        
        // Complex external calculations
        let damage = attackPower * (1 + (attackerLevel - defenderLevel) * 0.1);
        
        // External buff processing
        for (const buff of attackerBuffs) {
            if (buff.getType() === 'damage_boost') {
                damage *= 1 + buff.getValue();
            }
        }
        
        // External debuff processing
        for (const debuff of defenderDebuffs) {
            if (debuff.getType() === 'armor_reduction') {
                defenderArmor *= 1 - debuff.getValue();
            }
        }
        
        // External damage calculation
        const mitigatedDamage = Math.max(0, damage - defenderArmor);
        
        // External shield logic
        let remainingDamage = mitigatedDamage;
        if (defenderShield > 0) {
            if (defenderShield >= remainingDamage) {
                defender.setShield(defenderShield - remainingDamage);
                remainingDamage = 0;
            } else {
                remainingDamage -= defenderShield;
                defender.setShield(0);
            }
        }
        
        // External health modification
        const newHealth = Math.max(0, defenderHealth - remainingDamage);
        defender.setHealth(newHealth);
        
        // External status updates
        if (newHealth === 0) {
            defender.setStatus('dead');
            attacker.addExperience(defenderLevel * 10);
        }
        
        return new CombatResult(mitigatedDamage, newHealth === 0);
    }
}

Problems:

Combat logic is external to characters
Characters are passive stat containers
Adding new buffs/debuffs requires modifying the engine
Same calculations duplicated for different attack types
Character state freely manipulated from outside
Testing requires massive mocking

Notification System: Multi-Channel Delivery

Notification systems often involve complex rules about when, how, and to whom to send notifications. Let's see how TDA handles this elegantly.

notification-ask.ts
TypeScript
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
// Ask-Heavy: External orchestration
class NotificationSender {
    notify(userId: string, event: Event) {
        const user = this.userRepo.find(userId);
        const prefs = user.getPreferences();
        
        // Ask about every preference
        if (prefs.getEmailEnabled()) {
            const email = user.getEmail();
            if (email && prefs.getEmailFor(event.type)) {
                this.sendEmail(email, event.message);
            }
        }
        
        if (prefs.getSmsEnabled()) {
            const phone = user.getPhone();
            if (phone && prefs.getSmsFor(event.type)) {
                this.sendSms(phone, event.message);
            }
        }
        
        if (prefs.getPushEnabled()) {
            const tokens = user.getPushTokens();
            if (tokens.length > 0 && prefs.getPushFor(event.type)) {
                for (const token of tokens) {
                    this.sendPush(token, event.message);
                }
            }
        }
        
        // Log based on more extracted state
        if (prefs.getLogEnabled()) {
            this.logger.log(userId, event);
        }
    }
}

notification-tell.ts
TypeScript
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
// Tell-Oriented: User handles own notifications
class NotificationSender {
    notify(userId: string, event: Event) {
        const user = this.userRepo.find(userId);
        // Just tell the user to handle it
        user.notify(event);
    }
}
 
class User {
    private preferences: NotificationPreferences;
    private channels: NotificationChannel[];
    
    notify(event: Event): void {
        // User knows its channels and preferences
        const applicableChannels = this.channels
            .filter(ch => this.preferences.allows(ch, event.type));
        
        // Tell each channel to deliver
        applicableChannels.forEach(ch => ch.deliver(event));
    }
}
 
interface NotificationChannel {
    deliver(event: Event): void;
}
 
class EmailChannel implements NotificationChannel {
    constructor(private email: string) {}
    deliver(event: Event): void { /* ... */ }
}
 
class SmsChannel implements NotificationChannel {
    constructor(private phone: string) {}
    deliver(event: Event): void { /* ... */ }
}
 
class PushChannel implements NotificationChannel {
    constructor(private tokens: string[]) {}
    deliver(event: Event): void { /* ... */ }
}

The transformation highlights:

User as expert: The user knows its channels and preferences—the sender just tells it to notify
Polymorphic channels: Each channel implements deliver() its own way; adding Slack, Discord, etc. doesn't change the sender
Encapsulated preferences: Preference logic stays in NotificationPreferences, not scattered in the sender
Extensibility: New channels, new event types, new preference rules—all without touching NotificationSender

File Processing: Document Pipeline

Processing pipelines often involve chains of transformations. Let's see how TDA creates clean, extensible pipelines.

file-processing-comparison.ts
TypeScript
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
// Ask-Heavy: External processing with type checking
class DocumentProcessor {
    process(document: Document): ProcessedDocument {
        const type = document.getType();
        const content = document.getContent();
        const metadata = document.getMetadata();
        
        let processed: string;
        
        // Type-based branching with extracted data
        if (type === 'pdf') {
            processed = this.pdfParser.parse(content);
            const pageCount = this.pdfParser.getPageCount(content);
            metadata.set('pageCount', pageCount);
        } else if (type === 'word') {
            processed = this.wordParser.parse(content);
            const wordCount = this.wordParser.getWordCount(content);
            metadata.set('wordCount', wordCount);
        } else if (type === 'excel') {
            processed = this.excelParser.parse(content);
            const sheetCount = this.excelParser.getSheetCount(content);
            metadata.set('sheetCount', sheetCount);
        } else {
            processed = content.toString();
        }
        
        // More external processing
        const compressed = this.compressor.compress(processed);
        document.setProcessedContent(compressed);
        document.setMetadata(metadata);
        
        return new ProcessedDocument(document);
    }
}
 
// ================================================================
 
// Tell-Oriented: Documents process themselves
class DocumentProcessor {
    process(document: Document): ProcessedDocument {
        // Just tell the document to process
        return document.process();
    }
}
 
abstract class Document {
    protected content: Buffer;
    protected metadata: Metadata;
    
    abstract process(): ProcessedDocument;
    
    protected compress(text: string): Buffer {
        return Compressor.compress(text);
    }
}
 
class PdfDocument extends Document {
    process(): ProcessedDocument {
        const text = this.extractText();
        this.metadata.set('pageCount', this.countPages());
        const compressed = this.compress(text);
        return new ProcessedDocument(compressed, this.metadata);
    }
    
    private extractText(): string { /* PDF-specific extraction */ }
    private countPages(): number { /* PDF-specific counting */ }
}
 
class WordDocument extends Document {
    process(): ProcessedDocument {
        const text = this.extractText();
        this.metadata.set('wordCount', this.countWords());
        const compressed = this.compress(text);
        return new ProcessedDocument(compressed, this.metadata);
    }
    
    private extractText(): string { /* Word-specific extraction */ }
    private countWords(): number { /* Word-specific counting */ }
}
 
class ExcelDocument extends Document {
    process(): ProcessedDocument {
        const text = this.extractAllCells();
        this.metadata.set('sheetCount', this.countSheets());
        const compressed = this.compress(text);
        return new ProcessedDocument(compressed, this.metadata);
    }
    
    private extractAllCells(): string { /* Excel-specific extraction */ }
    private countSheets(): number { /* Excel-specific counting */ }
}

The Power of Polymorphism

Notice how adding a new document type (say, Markdown) in the tell-oriented version requires only creating a new class. The processor never changes. In the ask-oriented version, every new type requires modifying the processor—a direct violation of the Open/Closed Principle.

State Machines: Order Lifecycle

State machines are everywhere in software—order processing, workflow engines, game states. TDA makes state transitions safe and encapsulated.

state-machine-example.ts
TypeScript
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
// Ask-Heavy: External state management
class OrderWorkflow {
    ship(orderId: string): void {
        const order = this.orderRepo.find(orderId);
        const status = order.getStatus();
        
        // External validation of state transitions
        if (status !== 'paid') {
            throw new Error(
                `Cannot ship order in status ${status}`
            );
        }
        
        // External state change
        order.setStatus('shipped');
        order.setShippedAt(new Date());
        
        // External side effects
        const customer = order.getCustomer();
        this.emailService.sendShippingNotification(
            customer.getEmail(),
            order.getTrackingNumber()
        );
    }
    
    cancel(orderId: string): void {
        const order = this.orderRepo.find(orderId);
        const status = order.getStatus();
        
        // Duplicated transition logic
        if (status === 'shipped' || status === 'delivered') {
            throw new Error('Cannot cancel shipped order');
        }
        
        order.setStatus('cancelled');
        order.setCancelledAt(new Date());
        
        // Refund logic based on previous status
        if (status === 'paid') {
            this.refundService.refund(order.getPaymentId());
        }
    }
}
 
// ================================================================
 
// Tell-Oriented: Order manages its own state machine
class OrderWorkflow {
    ship(orderId: string): void {
        const order = this.orderRepo.find(orderId);
        order.ship();  // Tell order to transition
        this.orderRepo.save(order);
    }
    
    cancel(orderId: string): void {
        const order = this.orderRepo.find(orderId);
        order.cancel();  // Tell order to transition
        this.orderRepo.save(order);
    }
}
 
class Order {
    private status: OrderStatus;
    private customer: Customer;
    private payment?: Payment;
    private timestamps: OrderTimestamps;
    private events: DomainEvent[] = [];
    
    ship(): void {
        // Order validates its own transitions
        this.status.ensureCanTransitionTo(OrderStatus.Shipped);
        
        // Order performs transition
        this.status = OrderStatus.Shipped;
        this.timestamps.shipped = new Date();
        
        // Order raises events for side effects
        this.events.push(new OrderShippedEvent(this.id, this.customer.id));
    }
    
    cancel(): void {
        this.status.ensureCanTransitionTo(OrderStatus.Cancelled);
        
        const previousStatus = this.status;
        this.status = OrderStatus.Cancelled;
        this.timestamps.cancelled = new Date();
        
        // Order knows when refund is needed
        if (previousStatus === OrderStatus.Paid) {
            this.events.push(new RefundRequestedEvent(this.payment!.id));
        }
        
        this.events.push(new OrderCancelledEvent(this.id));
    }
    
    getEvents(): DomainEvent[] {
        return [...this.events];
    }
}
 
class OrderStatus {
    private static transitions: Map<OrderStatus, OrderStatus[]> = /* ... */;
    
    ensureCanTransitionTo(target: OrderStatus): void {
        const allowed = OrderStatus.transitions.get(this) || [];
        if (!allowed.includes(target)) {
            throw new InvalidTransitionError(this, target);
        }
    }
}

State machine benefits with TDA:

Transition rules encapsulated: The OrderStatus class knows what transitions are valid
No external state manipulation: Status changes happen inside Order
Domain events for side effects: Instead of calling services directly, Order raises events
Single source of truth: All state logic is in one place
Easy to test: Test Order's state transitions in isolation
Easy to extend: New statuses or rules don't touch the workflow service

Validation: Self-Validating Objects

Validation is a prime area where TDA shines. Instead of external validators interrogating objects, objects validate themselves.

External Validation Problems

•Validation logic duplicated across validators
•Objects can exist in invalid states
•Callers must remember to validate
•Validation rules scattered
•Object internals exposed for validation
•Easy to forget validation in new code paths

Self-Validating Object Benefits

•Validation rules in one place
•Objects are always valid (or don't exist)
•Impossble to forget validation
•Rules cohesive with data
•Internals hidden
•New code paths automatically validated

self-validating-objects.ts
TypeScript
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
// Value Object with self-validation: Email
class Email {
    private readonly value: string;
    
    private constructor(value: string) {
        this.value = value;
    }
    
    static create(value: string): Email {
        // Validation happens at creation
        if (!value || value.trim().length === 0) {
            throw new InvalidEmailError('Email cannot be empty');
        }
        if (!Email.isValidFormat(value)) {
            throw new InvalidEmailError(`Invalid email format: ${value}`);
        }
        if (!Email.isAllowedDomain(value)) {
            throw new InvalidEmailError(`Domain not allowed: ${value}`);
        }
        return new Email(value.toLowerCase().trim());
    }
    
    private static isValidFormat(value: string): boolean {
        return /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(value);
    }
    
    private static isAllowedDomain(value: string): boolean {
        const blockedDomains = ['tempmail.com', 'throwaway.net'];
        const domain = value.split('@')[1];
        return !blockedDomains.includes(domain);
    }
    
    getDomain(): string {
        return this.value.split('@')[1];
    }
    
    toString(): string {
        return this.value;
    }
}
 
// Entity with self-validation: User
class User {
    private email: Email;  // Always valid - Email validates itself
    private name: UserName;  // Always valid - UserName validates itself
    private age: Age;  // Always valid - Age validates itself
    
    private constructor(email: Email, name: UserName, age: Age) {
        this.email = email;
        this.name = name;
        this.age = age;
    }
    
    static create(emailStr: string, nameStr: string, ageNum: number): User {
        // Each value object validates on creation
        const email = Email.create(emailStr);
        const name = UserName.create(nameStr);
        const age = Age.create(ageNum);
        
        return new User(email, name, age);
    }
    
    updateEmail(newEmailStr: string): void {
        // Validation happens automatically in Email.create
        this.email = Email.create(newEmailStr);
    }
}
 
// Usage: impossible to create invalid objects
try {
    const user = User.create('invalid-email', 'Jo', -5);
} catch (error) {
    // Will fail at Email.create with clear error
}
 
const validUser = User.create('john@example.com', 'John Doe', 30);
// validUser is guaranteed to be valid - no external validation needed

Always-Valid Objects

When objects validate themselves at construction and on every mutation, they are 'always valid.' You never need to check 'is this object valid?' because invalid objects simply don't exist. This eliminates entire categories of bugs and makes reasoning about code dramatically simpler.

Summary: Tell, Don't Ask in Action

We've seen Tell, Don't Ask applied across diverse domains. Let's summarize the patterns:

TDA Patterns Across Domains

•E-Commerce (Cart): Cart knows how to checkout—items, promos, customers handle their own calculations.
•Banking (Transfers): Accounts validate, debit, and credit themselves—transactions are atomic operations told to objects.
•Gaming (Combat): Characters attack and receive attacks—buffs, equipment, and stats are polymorphic.
•Notifications: Users know their channels and preferences—channels deliver polymorphically.
•File Processing: Documents process themselves—type-specific logic through polymorphism, not conditionals.
•State Machines: Objects manage their own transitions—validation and side effects encapsulated.
•Validation: Objects validate themselves at creation—always-valid objects eliminate entire bug categories.

The Common Thread:

In every example, the transformation follows the same pattern:

Before: External code extracts state, performs logic, modifies state
After: External code tells objects what to do; objects handle internals

The result is always:

Higher cohesion — Logic lives with its data
Lower coupling — Callers don't know internals
Better encapsulation — State changes are internal
Easier extension — New types/variations through polymorphism
Simpler testing — Objects test their own behavior

What's Next:

While Tell, Don't Ask is a powerful principle, it's not absolute. The final page explores when asking is appropriate—legitimate cases where queries are necessary and beneficial, and how to balance pure TDA with practical realities.

Page Complete

You've now seen Tell, Don't Ask applied across e-commerce, banking, gaming, notifications, file processing, state machines, and validation. These patterns will recur throughout your career—you're now equipped to recognize opportunities and apply TDA transformations instinctively.

Tell, Don't Ask Examples

Principles in Practice

What You Will Learn

E-Commerce: Shopping Cart Operations

Shopping carts are ubiquitous in e-commerce systems. Let's examine how TDA transforms cart operations from procedural to object-oriented.

cart-ask-heavy.ts
TypeScript
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
// Ask-Heavy Anti-Pattern: Procedural cart processing
class CartCheckoutService {
    checkout(cart: Cart): Order {
        // Asking cart for its data
        const items = cart.getItems();
        const customerId = cart.getCustomerId();
        const promoCode = cart.getPromoCode();
        
        // Performing calculations externally
        let subtotal = 0;
        for (const item of items) {
            const price = item.getPrice();
            const quantity = item.getQuantity();
            subtotal += price * quantity;
        }
        
        // More external logic based on cart state
        let discount = 0;
        if (promoCode) {
            const promo = this.promoService.getPromo(promoCode);
            if (promo.getType() === 'percentage') {
                discount = subtotal * promo.getValue() / 100;
            } else if (promo.getType() === 'fixed') {
                discount = promo.getValue();
            }
        }
        
        // Checking customer status externally
        const customer = this.customerService.getCustomer(customerId);
        if (customer.getMembershipLevel() === 'premium') {
            discount += subtotal * 0.05; // Extra 5% for premium
        }
        
        const total = subtotal - discount;
        
        // Validating externally
        if (items.length === 0) {
            throw new Error('Cart is empty');
        }
        if (total < 0) {
            throw new Error('Invalid total');
        }
        
        // Creating order with extracted data
        const order = new Order();
        order.setCustomerId(customerId);
        order.setItems(items);
        order.setSubtotal(subtotal);
        order.setDiscount(discount);
        order.setTotal(total);
        
        // Clearing cart externally
        cart.setItems([]);
        cart.setPromoCode(null);
        
        return order;
    }
}

Problems with this approach:

Cart is a passive data container
Business logic (pricing, discounts) scattered in service
Validation happens externally, after state extraction
Duplicated calculations across services
Cart state mutated externally (broken encapsulation)
Testing requires mocking many getters

Banking: Account Transfers

Banking operations are classic examples where TDA dramatically improves code quality and safety. Let's examine money transfers.

bank-ask-heavy.ts
TypeScript
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
// Ask-Heavy Anti-Pattern: External manipulation
class TransferService {
    transfer(
        sourceId: string, 
        targetId: string, 
        amount: number
    ): TransferResult {
        const source = this.accountRepo.find(sourceId);
        const target = this.accountRepo.find(targetId);
        
        // Asking accounts for their state
        const sourceBalance = source.getBalance();
        const sourceStatus = source.getStatus();
        const sourceLimit = source.getDailyLimit();
        const todaysTransfers = source.getTodaysTransferTotal();
        
        const targetStatus = target.getStatus();
        const targetType = target.getType();
        
        // External validation using extracted state
        if (sourceStatus !== 'active') {
            throw new Error('Source account inactive');
        }
        if (targetStatus !== 'active') {
            throw new Error('Target account inactive');
        }
        if (sourceBalance < amount) {
            throw new Error('Insufficient funds');
        }
        if (todaysTransfers + amount > sourceLimit) {
            throw new Error('Daily limit exceeded');
        }
        if (targetType === 'closed' || targetType === 'frozen') {
            throw new Error('Cannot transfer to this account');
        }
        
        // External state manipulation
        source.setBalance(sourceBalance - amount);
        source.setTodaysTransferTotal(todaysTransfers + amount);
        target.setBalance(target.getBalance() + amount);
        
        // External record keeping
        source.addTransaction(new Transaction('debit', amount, targetId));
        target.addTransaction(new Transaction('credit', amount, sourceId));
        
        return new TransferResult(true, source.getBalance());
    }
}

Problems:

Business rules (limits, status checks) extracted from accounts
Account state manipulated externally—dangerous!
Transaction records created externally
Same validation logic would be duplicated for withdrawals, payments
Race condition risks with external get/set patterns

Domain Events

Gaming: Character Combat

Game development offers rich examples where TDA keeps combat systems maintainable. Let's examine character-vs-character combat.

game-ask-heavy.ts
TypeScript
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
// Ask-Heavy Anti-Pattern: External combat logic
class CombatEngine {
    attack(attacker: Character, defender: Character): CombatResult {
        // Asking characters for all their stats
        const attackPower = attacker.getStrength() + attacker.getWeaponDamage();
        const attackerLevel = attacker.getLevel();
        const attackerBuffs = attacker.getActiveBuffs();
        
        const defenderArmor = defender.getArmor();
        const defenderLevel = defender.getLevel();
        const defenderHealth = defender.getHealth();
        const defenderShield = defender.getShield();
        const defenderDebuffs = defender.getActiveDebuffs();
        
        // Complex external calculations
        let damage = attackPower * (1 + (attackerLevel - defenderLevel) * 0.1);
        
        // External buff processing
        for (const buff of attackerBuffs) {
            if (buff.getType() === 'damage_boost') {
                damage *= 1 + buff.getValue();
            }
        }
        
        // External debuff processing
        for (const debuff of defenderDebuffs) {
            if (debuff.getType() === 'armor_reduction') {
                defenderArmor *= 1 - debuff.getValue();
            }
        }
        
        // External damage calculation
        const mitigatedDamage = Math.max(0, damage - defenderArmor);
        
        // External shield logic
        let remainingDamage = mitigatedDamage;
        if (defenderShield > 0) {
            if (defenderShield >= remainingDamage) {
                defender.setShield(defenderShield - remainingDamage);
                remainingDamage = 0;
            } else {
                remainingDamage -= defenderShield;
                defender.setShield(0);
            }
        }
        
        // External health modification
        const newHealth = Math.max(0, defenderHealth - remainingDamage);
        defender.setHealth(newHealth);
        
        // External status updates
        if (newHealth === 0) {
            defender.setStatus('dead');
            attacker.addExperience(defenderLevel * 10);
        }
        
        return new CombatResult(mitigatedDamage, newHealth === 0);
    }
}

Problems:

Combat logic is external to characters
Characters are passive stat containers
Adding new buffs/debuffs requires modifying the engine
Same calculations duplicated for different attack types
Character state freely manipulated from outside
Testing requires massive mocking

Notification System: Multi-Channel Delivery

Notification systems often involve complex rules about when, how, and to whom to send notifications. Let's see how TDA handles this elegantly.

notification-ask.ts
TypeScript
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
// Ask-Heavy: External orchestration
class NotificationSender {
    notify(userId: string, event: Event) {
        const user = this.userRepo.find(userId);
        const prefs = user.getPreferences();
        
        // Ask about every preference
        if (prefs.getEmailEnabled()) {
            const email = user.getEmail();
            if (email && prefs.getEmailFor(event.type)) {
                this.sendEmail(email, event.message);
            }
        }
        
        if (prefs.getSmsEnabled()) {
            const phone = user.getPhone();
            if (phone && prefs.getSmsFor(event.type)) {
                this.sendSms(phone, event.message);
            }
        }
        
        if (prefs.getPushEnabled()) {
            const tokens = user.getPushTokens();
            if (tokens.length > 0 && prefs.getPushFor(event.type)) {
                for (const token of tokens) {
                    this.sendPush(token, event.message);
                }
            }
        }
        
        // Log based on more extracted state
        if (prefs.getLogEnabled()) {
            this.logger.log(userId, event);
        }
    }
}

notification-tell.ts
TypeScript
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
// Tell-Oriented: User handles own notifications
class NotificationSender {
    notify(userId: string, event: Event) {
        const user = this.userRepo.find(userId);
        // Just tell the user to handle it
        user.notify(event);
    }
}
 
class User {
    private preferences: NotificationPreferences;
    private channels: NotificationChannel[];
    
    notify(event: Event): void {
        // User knows its channels and preferences
        const applicableChannels = this.channels
            .filter(ch => this.preferences.allows(ch, event.type));
        
        // Tell each channel to deliver
        applicableChannels.forEach(ch => ch.deliver(event));
    }
}
 
interface NotificationChannel {
    deliver(event: Event): void;
}
 
class EmailChannel implements NotificationChannel {
    constructor(private email: string) {}
    deliver(event: Event): void { /* ... */ }
}
 
class SmsChannel implements NotificationChannel {
    constructor(private phone: string) {}
    deliver(event: Event): void { /* ... */ }
}
 
class PushChannel implements NotificationChannel {
    constructor(private tokens: string[]) {}
    deliver(event: Event): void { /* ... */ }
}

The transformation highlights:

User as expert: The user knows its channels and preferences—the sender just tells it to notify
Polymorphic channels: Each channel implements deliver() its own way; adding Slack, Discord, etc. doesn't change the sender
Encapsulated preferences: Preference logic stays in NotificationPreferences, not scattered in the sender
Extensibility: New channels, new event types, new preference rules—all without touching NotificationSender

File Processing: Document Pipeline

Processing pipelines often involve chains of transformations. Let's see how TDA creates clean, extensible pipelines.

file-processing-comparison.ts
TypeScript
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
// Ask-Heavy: External processing with type checking
class DocumentProcessor {
    process(document: Document): ProcessedDocument {
        const type = document.getType();
        const content = document.getContent();
        const metadata = document.getMetadata();
        
        let processed: string;
        
        // Type-based branching with extracted data
        if (type === 'pdf') {
            processed = this.pdfParser.parse(content);
            const pageCount = this.pdfParser.getPageCount(content);
            metadata.set('pageCount', pageCount);
        } else if (type === 'word') {
            processed = this.wordParser.parse(content);
            const wordCount = this.wordParser.getWordCount(content);
            metadata.set('wordCount', wordCount);
        } else if (type === 'excel') {
            processed = this.excelParser.parse(content);
            const sheetCount = this.excelParser.getSheetCount(content);
            metadata.set('sheetCount', sheetCount);
        } else {
            processed = content.toString();
        }
        
        // More external processing
        const compressed = this.compressor.compress(processed);
        document.setProcessedContent(compressed);
        document.setMetadata(metadata);
        
        return new ProcessedDocument(document);
    }
}
 
// ================================================================
 
// Tell-Oriented: Documents process themselves
class DocumentProcessor {
    process(document: Document): ProcessedDocument {
        // Just tell the document to process
        return document.process();
    }
}
 
abstract class Document {
    protected content: Buffer;
    protected metadata: Metadata;
    
    abstract process(): ProcessedDocument;
    
    protected compress(text: string): Buffer {
        return Compressor.compress(text);
    }
}
 
class PdfDocument extends Document {
    process(): ProcessedDocument {
        const text = this.extractText();
        this.metadata.set('pageCount', this.countPages());
        const compressed = this.compress(text);
        return new ProcessedDocument(compressed, this.metadata);
    }
    
    private extractText(): string { /* PDF-specific extraction */ }
    private countPages(): number { /* PDF-specific counting */ }
}
 
class WordDocument extends Document {
    process(): ProcessedDocument {
        const text = this.extractText();
        this.metadata.set('wordCount', this.countWords());
        const compressed = this.compress(text);
        return new ProcessedDocument(compressed, this.metadata);
    }
    
    private extractText(): string { /* Word-specific extraction */ }
    private countWords(): number { /* Word-specific counting */ }
}
 
class ExcelDocument extends Document {
    process(): ProcessedDocument {
        const text = this.extractAllCells();
        this.metadata.set('sheetCount', this.countSheets());
        const compressed = this.compress(text);
        return new ProcessedDocument(compressed, this.metadata);
    }
    
    private extractAllCells(): string { /* Excel-specific extraction */ }
    private countSheets(): number { /* Excel-specific counting */ }
}

The Power of Polymorphism

State Machines: Order Lifecycle

State machines are everywhere in software—order processing, workflow engines, game states. TDA makes state transitions safe and encapsulated.

state-machine-example.ts
TypeScript
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
// Ask-Heavy: External state management
class OrderWorkflow {
    ship(orderId: string): void {
        const order = this.orderRepo.find(orderId);
        const status = order.getStatus();
        
        // External validation of state transitions
        if (status !== 'paid') {
            throw new Error(
                `Cannot ship order in status ${status}`
            );
        }
        
        // External state change
        order.setStatus('shipped');
        order.setShippedAt(new Date());
        
        // External side effects
        const customer = order.getCustomer();
        this.emailService.sendShippingNotification(
            customer.getEmail(),
            order.getTrackingNumber()
        );
    }
    
    cancel(orderId: string): void {
        const order = this.orderRepo.find(orderId);
        const status = order.getStatus();
        
        // Duplicated transition logic
        if (status === 'shipped' || status === 'delivered') {
            throw new Error('Cannot cancel shipped order');
        }
        
        order.setStatus('cancelled');
        order.setCancelledAt(new Date());
        
        // Refund logic based on previous status
        if (status === 'paid') {
            this.refundService.refund(order.getPaymentId());
        }
    }
}
 
// ================================================================
 
// Tell-Oriented: Order manages its own state machine
class OrderWorkflow {
    ship(orderId: string): void {
        const order = this.orderRepo.find(orderId);
        order.ship();  // Tell order to transition
        this.orderRepo.save(order);
    }
    
    cancel(orderId: string): void {
        const order = this.orderRepo.find(orderId);
        order.cancel();  // Tell order to transition
        this.orderRepo.save(order);
    }
}
 
class Order {
    private status: OrderStatus;
    private customer: Customer;
    private payment?: Payment;
    private timestamps: OrderTimestamps;
    private events: DomainEvent[] = [];
    
    ship(): void {
        // Order validates its own transitions
        this.status.ensureCanTransitionTo(OrderStatus.Shipped);
        
        // Order performs transition
        this.status = OrderStatus.Shipped;
        this.timestamps.shipped = new Date();
        
        // Order raises events for side effects
        this.events.push(new OrderShippedEvent(this.id, this.customer.id));
    }
    
    cancel(): void {
        this.status.ensureCanTransitionTo(OrderStatus.Cancelled);
        
        const previousStatus = this.status;
        this.status = OrderStatus.Cancelled;
        this.timestamps.cancelled = new Date();
        
        // Order knows when refund is needed
        if (previousStatus === OrderStatus.Paid) {
            this.events.push(new RefundRequestedEvent(this.payment!.id));
        }
        
        this.events.push(new OrderCancelledEvent(this.id));
    }
    
    getEvents(): DomainEvent[] {
        return [...this.events];
    }
}
 
class OrderStatus {
    private static transitions: Map<OrderStatus, OrderStatus[]> = /* ... */;
    
    ensureCanTransitionTo(target: OrderStatus): void {
        const allowed = OrderStatus.transitions.get(this) || [];
        if (!allowed.includes(target)) {
            throw new InvalidTransitionError(this, target);
        }
    }
}

State machine benefits with TDA:

Transition rules encapsulated: The OrderStatus class knows what transitions are valid
No external state manipulation: Status changes happen inside Order
Domain events for side effects: Instead of calling services directly, Order raises events
Single source of truth: All state logic is in one place
Easy to test: Test Order's state transitions in isolation
Easy to extend: New statuses or rules don't touch the workflow service

Validation: Self-Validating Objects

Validation is a prime area where TDA shines. Instead of external validators interrogating objects, objects validate themselves.

External Validation Problems

•Validation logic duplicated across validators
•Objects can exist in invalid states
•Callers must remember to validate
•Validation rules scattered
•Object internals exposed for validation
•Easy to forget validation in new code paths

Self-Validating Object Benefits

•Validation rules in one place
•Objects are always valid (or don't exist)
•Impossble to forget validation
•Rules cohesive with data
•Internals hidden
•New code paths automatically validated

self-validating-objects.ts
TypeScript
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
// Value Object with self-validation: Email
class Email {
    private readonly value: string;
    
    private constructor(value: string) {
        this.value = value;
    }
    
    static create(value: string): Email {
        // Validation happens at creation
        if (!value || value.trim().length === 0) {
            throw new InvalidEmailError('Email cannot be empty');
        }
        if (!Email.isValidFormat(value)) {
            throw new InvalidEmailError(`Invalid email format: ${value}`);
        }
        if (!Email.isAllowedDomain(value)) {
            throw new InvalidEmailError(`Domain not allowed: ${value}`);
        }
        return new Email(value.toLowerCase().trim());
    }
    
    private static isValidFormat(value: string): boolean {
        return /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(value);
    }
    
    private static isAllowedDomain(value: string): boolean {
        const blockedDomains = ['tempmail.com', 'throwaway.net'];
        const domain = value.split('@')[1];
        return !blockedDomains.includes(domain);
    }
    
    getDomain(): string {
        return this.value.split('@')[1];
    }
    
    toString(): string {
        return this.value;
    }
}
 
// Entity with self-validation: User
class User {
    private email: Email;  // Always valid - Email validates itself
    private name: UserName;  // Always valid - UserName validates itself
    private age: Age;  // Always valid - Age validates itself
    
    private constructor(email: Email, name: UserName, age: Age) {
        this.email = email;
        this.name = name;
        this.age = age;
    }
    
    static create(emailStr: string, nameStr: string, ageNum: number): User {
        // Each value object validates on creation
        const email = Email.create(emailStr);
        const name = UserName.create(nameStr);
        const age = Age.create(ageNum);
        
        return new User(email, name, age);
    }
    
    updateEmail(newEmailStr: string): void {
        // Validation happens automatically in Email.create
        this.email = Email.create(newEmailStr);
    }
}
 
// Usage: impossible to create invalid objects
try {
    const user = User.create('invalid-email', 'Jo', -5);
} catch (error) {
    // Will fail at Email.create with clear error
}
 
const validUser = User.create('john@example.com', 'John Doe', 30);
// validUser is guaranteed to be valid - no external validation needed

Always-Valid Objects

Summary: Tell, Don't Ask in Action

We've seen Tell, Don't Ask applied across diverse domains. Let's summarize the patterns:

TDA Patterns Across Domains

•E-Commerce (Cart): Cart knows how to checkout—items, promos, customers handle their own calculations.
•Banking (Transfers): Accounts validate, debit, and credit themselves—transactions are atomic operations told to objects.
•Gaming (Combat): Characters attack and receive attacks—buffs, equipment, and stats are polymorphic.
•Notifications: Users know their channels and preferences—channels deliver polymorphically.
•File Processing: Documents process themselves—type-specific logic through polymorphism, not conditionals.
•State Machines: Objects manage their own transitions—validation and side effects encapsulated.
•Validation: Objects validate themselves at creation—always-valid objects eliminate entire bug categories.

The Common Thread:

In every example, the transformation follows the same pattern:

Before: External code extracts state, performs logic, modifies state
After: External code tells objects what to do; objects handle internals

The result is always:

Higher cohesion — Logic lives with its data
Lower coupling — Callers don't know internals
Better encapsulation — State changes are internal
Easier extension — New types/variations through polymorphism
Simpler testing — Objects test their own behavior

What's Next:

Page Complete