4 Domain Modeling with Algebraic Data Types
This chapter covers
- The walk through the messy design process
- Modeling with Algebraic Data Types
- Making Illegal states impossible to represent
We’re going to walk through designing a small feature in all of its chaotic glory. Data-oriented design is like all design processes: iterative and messy. We’ll make plenty of missteps, hit lots of dead ends, and have to do more than a few total resets. We’ll walk through all those messy bits here because we’d do them in real life, too (at least when I’m doing it). However, beyond that, we walk through all the “wrong” parts so that we can train ourselves to become sensitive to the friction that “wrong” causes in the code. Once we can identify problems, fixing them becomes much easier.
What might be surprising is that our design process will be focused entirely on the data in our domain and what it means. Data Oriented design is largely in the spirit of Fred Brooks’ classic observation from Mythical Man Month: “representation is the essence of programming.” If we get the representation of our data right, everything else tends to fall into place. As such, we won’t worry about behaviors, or efficiency, design patterns, or any other operational focused concerns for now.
We're also going to ignore that our job as software engineers is to build systems.