Domain Modeling

Overview

The names and shapes you give the concepts in your code are the design. When you introduce a new domain concept, name it for what it means in the user's world, give it a real type, and decide where its state lives — before you write the methods that act on it.

This is a rigid skill. Run the decisions in order. If you can't satisfy one, stop and tell the user what's blocking you. When the concept is exposed across a module/package/service boundary, also invoke api-design (overlap on type design and value-vs-identity).

When to invoke

Invoke when you're about to:

• Introduce a new top-level type, class, struct, record, or table that represents a thing in the domain (Trader, Portfolio, Booking, Invoice, Reservation)
• Rename an existing domain concept across files
• Add a new database table or persistent collection
• Decide whether a chunk of state should live in memory, in a file, in a key-value store, or in a relational database
• Replace primitive-typed data (int, string, Map<int, Map<int, int>>) with named domain types
• Sketch the data model for a new feature, area, or service
• Evaluate whether an existing domain model is well-structured, or review naming and type choices