RADIO — Core Entities

Identifying the core entities your UI is built around.

The architecture diagram kept saying “data” — this component sends data, that one reads data. The D step finally asks: what is that data? We describe the system from the data's point of view — its core entities and where each one lives.

The architecture told us pieces exchange data. Now we model it. Tap D:

A data entity is a block of data you can name with a single word — a Post, a Comment, a User. The D step identifies the core entities in your system, the fields each one holds, and which component or module owns them. That's what lets you say precisely “the store holds the posts; the header reads the author.”

Almost every system mixes two sources of data, and telling them apart decides where each piece should live:

Don't just say “username.” Say its type. TypeScript-style notation is the clearest way to pin a field down so whoever reads the design knows exactly what shape arrives:

username: string
age: number
comments: Comment[]   // an array of Comment entities

That last line matters: when a component expects Comment[], everyone knows it renders a list, not a single item.

Before the abstract boxes, here's the thing we're actually modeling — one feed post. Every region on screen maps to an entity (tagged in the corners):

Turn that screen into data. Four entities cover the feed; notice how relations (the green types) stitch them together — a Post owns Comment[] and a User author:

Those cards are only half the story — the relations are what make it a model. Tap an entity to trace what it owns:

For each piece of data in the feed, decide where it originates — which tells you whether it belongs in the store/DB or as transient component state:

Three habits keep your data model from turning into a bug farm:

// avoid: a second source of truth
const [isEmpty, setIsEmpty] = useState(true)

// prefer: derive it on the fly
const isEmpty = items.length === 0

Model the data for a simple chat window:

1. Write the Message and Conversation entities with typed fields.
2. List which data is server-originated vs client-originated.
3. Find one value you were tempted to store but could derive instead.