Modeling Real-World Problems
The first thing an experienced engineer does when given a new feature request isn't write code — it's model the domain. What are the entities? How do they relate? What states can they be in? What transitions are valid? What business rules need to be enforced? Getting these answers right before writing a line of code is what separates a system that's easy to extend from one that collapses under its own weight six months later. Vibe coders skip this step. They generate CRUD endpoints before thinking about the data model, bolt on state management as an afterthought, and encode business rules in whatever place is most convenient at the time. The result is a system that technically works for the happy path and silently corrupts data everywhere else. This module teaches you to think in domains before you think in code. You'll model entities and their relationships using ER diagrams, design state machines that prevent invalid transitions, express business rules as code constraints rather than scattered conditionals, and work through real-world modeling exercises covering e-commerce, hotel booking, and social networks. The capstone project — a restaurant reservation system — puts all of these skills together into a complete, correctly modeled domain.
What You'll Learn
-
1
Entity Modeling — Identifying the nouns in a domain, attributes vs entities, identity
-
2
Relationship Modeling — One-to-one, one-to-many, many-to-many, ER diagrams
-
3
State Machines — Modeling entity lifecycles, states, transitions, and events
-
4
Business Rules as Code — Validation vs business rules, centralizing constraints
-
5
Event Modeling — Domains as sequences of events, commands, and read models
-
6
Domain Modeling Exercises — E-commerce, hotel booking, and social network systems
-
7
From Model to Code — Making invalid states unrepresentable in your implementation
Capstone Project: Model and Implement a Restaurant Reservation System
Design the complete domain model for a restaurant reservation system — tables, time slots, reservations, parties, waitlists, and cancellations — then implement it with proper state machines, relationship enforcement, and business rule validation. The system must make invalid states (double-booking a table, reserving in the past, over-capacity parties) impossible to represent, not just runtime errors to catch.
Why This Matters for Your Career
The cost of a wrong data model compounds over time. A system built on a correct model is easy to query, easy to extend, and easy to reason about. A system built on a wrong model requires increasingly complex workarounds, produces subtle data inconsistencies, and eventually becomes impossible to modify safely. The decision made in the first week — what are the entities and how do they relate — determines the quality of the system for its entire lifetime. State machines are one of the most underused tools in software engineering. Most systems have entities that can be in multiple states — orders, users, subscriptions, payments, deployments — and most engineers manage this with boolean flags and scattered conditionals rather than explicit state machines. The result is impossible-to-reason-about code where an entity can be simultaneously active and cancelled because some flag was updated but not another. Making invalid states unrepresentable — using types, constraints, and design to make incorrect data literally impossible to create — is a paradigm shift in how you approach correctness. Instead of validating everywhere you use data, you validate once when it enters the system and trust it everywhere else. This is the philosophy behind TypeScript's discriminated unions, database constraints, and well-designed domain models.