4 Domain Modeling with Algebraic Data Types

In this chapter, the author walks through a deliberately messy, real-world style design process for a rocket-manufacturing checklist feature, using the friction in the code as a signal that the model and the domain meaning are drifting apart. The narrative starts from vague requirements and repeatedly refines them by asking what the data really means, rather than by adding behavior or defensive code first. Along the way, the checklist is split into distinct concepts such as templates, instances, and step status, showing how careful modeling can replace ambiguity with structure.

The core lesson is that records are best understood as modeling AND: each field contributes to a cartesian-product style combination of attributes. That makes records powerful for expressing things that belong together, but dangerous when unrelated states are forced into one type, because the result is often nulls, illegal combinations, and lots of validation code. The chapter demonstrates this with a checklist status model that first seems simple, then becomes awkward as completion and skipping metadata are added, and finally improves when those contextual attributes are recognized as describing distinct states rather than one overloaded record.

To model those distinct states, the chapter introduces sealed interfaces as a way to express OR: a checklist status is one of several permitted variants, and no others. This creates a closed family of data types that matches the domain more precisely, makes illegal states impossible to represent, and reduces the need for defensive programming. The chapter then ties these Java features to algebraic data types, explaining records as product types and sealed interfaces as sum types, and showing how their algebraic laws can guide safe refactoring and help developers reason about meaning, invariants, and valid state spaces more clearly.