← Contents · Runnable Specifications by Eric Normand · Work in progress · Comments
1
Introduction
A friend in the book business told me the introduction is oen
read by someone standing in a bookstore, deciding whether to
buy the book. If that’s you, then welcome! I hope this introduc-
tion gives you what you need to make a buying decision. If you
already own the book, it will orient and ready you for the rest of
the book.
All programmers design soware, so we have a sense for what
it means. However, I will dene it so we are on the same page. I
also want you to understand the slightly cryptic title of the book.
And nally, you should understand how I intended you to use the
book to maximize your learning and make it worth your time and
money.
Introduction objectives
• Understand the main ideas of this book.
• Decide if this book is for you.
• Contrast this book with other soware design approaches.
• Learn how to maximize your learning from this book.
Important terms
• soware design
• domain
• domain modeling
• runnable specications
1
2
Introduction
Soware design means making programming decisions
This is a book about soware design. But what does that term
mean?
Soware design is making decisions about how we write the
soware. While coding, we face countless choices: Do I use a for
loop or a while loop? Do I break this function into two smaller
functions? How do I name them? What types should the func-
tion’s arguments be? What data structure should I use? Where
should I break up my modules? Soware design encompasses all
of these decisions, from high-level architecture to line-by-line
coding choices.
But wait—if soware design includes every decision we make
while programming, isn’t it just programming by another name?
And shouldn’t we distinguish between dierent types of deci-
sions—architectural choices versus implementation details, stra-
tegic versus tactical, important versus routine? Many try to draw
these lines, to separate “design” from “mere programming.”
Any attempt to separate design from programming articial-
ly fragments the holistic process. Each low-level decision ripples
through the system: a choice of data structure aects memory
usage, which aects performance, which aects user experience.
Design isn’t a separate phase or activity—it’s our awareness of the
decisions we’re making at every level.
This denition serves a specic purpose: to bring attention to
the countless decisions we make while programming. Many of
these decisions have become unconscious habits over years of
practice. By viewing programming as design—as a series of con-
scious choices—we can examine these decisions more carefully.
And we need to examine them carefully, because these deci-
sions are far from easy. Let’s look at why making design decisions
is so challenging.
3Introduction
Making design decisions is hard
Soware design decisions are hard for three fundamental rea-
sons. First, there are thousands if not millions of design decisions
to make when building a signicant piece of soware.
Second, each decision has multiple consequences—a single
choice might aect performance, readability, maintainability,
and other qualities of our code all at once.
Third, decisions are interlinked: when you change one deci-
sion, you have to re-evaluate all the decisions that depend on it.
Together, these characteristics make soware design overwhelm-
ing. It’s too big to t in our heads, and it’s nearly impossible to
understand even the rst-order consequences of our choices, let
alone the second-order ones.
As an industry, we’ve tried to tackle this complexity through
apprenticeship—senior programmers working closely with ju-
niors. The senior programmers typically impart rules-of-them
and principles. It works because seniors don’t just teach princi-
ples and rules; they provide constant guidance about when and
how to apply them.
But this success masks a deeper problem: our principles and
rules aren’t actually adequate expressions of design expertise.
When experts try to broadcast their knowledge through books
and talks, stripped of the interactive guidance, these same prin-
ciples oen lead to dogmatic, misguided application. One-on-one
mentorship works, but it doesn’t scale, and our attempts to scale
it have failed to capture the nuance that makes it eective.
We need a dierent approach. Instead of principles and rules,
this book is organized around perspectives. Each perspective
gives us a dierent way to look at the problem. By examining our
design decisions through multiple perspectives, we can begin to
assemble a holistic view of the soware we build—one that helps
us navigate the inherent complexity of soware design.
4
Introduction
We make better decisions with more information
If soware design means making decisions, then better design
means making better decisions. This transforms an abstract
challenge into a concrete one: instead of “improve design,” we
just need to make better decisions.
Consider what seems like a simple decision: choosing a data
structure for a coee order. Should we use an array? Even this
basic choice raises numerous questions. Does it enable or hinder
important use cases? Does it make the code easier to write and
read? Arrays maintain insertion order—does that help or hurt
when implementing features like adding or removing coees
from an order?
Without context, we can’t answer any of these questions. Each
one demands information—about requirements, about usage pat-
terns, about constraints. When we say “it depends,” we mean we
need more information to decide. A single decision like choosing
a data structure aects multiple concerns: usability, readability,
maintainability, performance.
This points to a deeper truth: the quality of our decisions de-
pends on the totality of information available to us—technical
context, business context, user needs, constraints, and more.
The key to better soware design isn’t just having good judgment;
it’s systematically gathering the information needed to exercise
that judgment.
This book will equip you with systematic ways to gather the
information needed for better design decisions. And the richest
source of this information lies in an oen-overlooked place: the
domain itself.
5Introduction
The domain is the best source of information
Domain modeling is an approach to soware design that uses the
domain as the primary source of information for making deci-
sions. This means that any time you have a question to answer,
you should rst look to the domain:
Q: How should I name this method?
A: What’s it called in the domain?
Q: Should I split this function in two?
A: Is it split in the domain?
Q: Should I add a layer of indirection?
A: Does it correspond to anything in the domain?
Q: Have I covered all of the cases?
A: Are there more cases in the domain?
However, this relationship goes both ways. Domain experts oen
have deep, intuitive knowledge that they’ve never had to formal-
ize. Soware’s need for explicit, unambiguous models can help
surface and clarify these domain concepts. When we say “look
to the domain,” we’re engaging in a dialogue where soware’s de-
mands for precision help make implicit knowledge explicit.
When code becomes messy or complex, most soware design
approaches treat the code itself as the problem. They focus on
symptoms: long methods, nested if statements, tight coupling.
But this gets it backwards. Complex, messy code is usually a
symptom of a deeper problem: the domain model failed to cap-
ture something important about the domain. When an essential
concept or relationship isn’t properly encoded in your model,
developers end up writing increasingly complex code to work
around this blind spot. It’s like trying to write music without the
concept of rhythm--you’d need countless markings to indicate
when each note should be played.
Approaches that focus on code metrics or code smells can help
you identify problems but can’t help you x the root cause. These
approaches avoid dealing with the domain because every domain
is dierent, and teaching domain analysis is harder than teaching
code cleanup. In this book, I will teach you to extract information
from the domain and encode it in your soware--while using so-
ware’s need for precision to help clarify the domain itself.
6
Introduction
We make better decisions by considering more options
Another way we can make better decisions is by considering more
options. When you’re playing chess, you make better moves by
considering more moves. Likewise, you make better decisions by
consider more options for each decision.
When we’re learning to program, there is so much to learn and
so many decisions to make, we are taught simple methodologies
that help us make progress. For instance, I was taught in school
that we should make a class for each concept in the problem de-
scription. That would mean if I had to build a university course
registry, I would make a Student class and a Course class.
Over years of experience, as our skills grow, we should drop
these simplistic methodologies, but oen we do not. They become
ingrained habits that we never question. When we are presented
with a design decision, we apply our habits and never consider
other options.
In my case, it took years of exploration and introspection for
me to rid myself of that habit that went back to my university’s
Object-Oriented Design course. It started with considering other
options. What if I used a plain data structure to hold the data for
a Student? What if I use functions instead of classes? What if I
model something besides what’s in the problem description?
By asking these questions and experimenting with dierent
design decisions, I got rid of the habit and became a better de-
signer. Throughout this book, we’ll work through this process
of questioning our defaults and exploring alternatives. The pro-
cess will give you new ways to see design options you might have
missed before, helping you break free from simplistic habits and
make more intentional design choices. (And of course, consider-
ing more options is only valuable if we can evaluate them well--
something we’ll explore in the next section.)
7Introduction
We make better decisions through better evaluation
Just as in chess, better decisions come not only from considering
more moves, but from evaluating those moves more eectively. A
novice and master might see the same ve choices, but the mas-
ter can evaluate tem better. The same applies to soware design-
-it’s not enough to see multiple options; we need better ways to
compare them.
For too long, I found myself frustrated in design discussions
that devolved into matters of personal taste. “It’s clearly better
but I can’t say why” was a common refrain, making it impossible
to learn from each other or make consistent decisions as a team.
Even worse, when I examined my own design choices, I realized
how much I relied on unarticulated intuition rather than system-
atic evaluation.
Through years of exploration, I’ve discovered we can evaluate
design decisions more objectively than I once thought possible.
We can examine if a data model has a clear, unambiguous map-
ping to the domain. We can verify if operations handle all valid
inputs. We can compare the semantic minimalism of dierent
models. We can analyze how operations compose and measure
their algorithmic complexity.
These ideas aren’t rules like “functions should be ve lines or
shorter,” which are objective yet arbitrary and focused on style
(the symptoms). They are measures of how well our code encodes
the structure of the domain. They give us ways to ensure the
quality of our model.
These evaluation criteria don’t replace judgment--they inform
it. Each criterion illuminates one aspect of a design decision, like
examining a jewel through dierent lenses. The nal decision
still requires integrating these various perspectives. But by using
more systematic evaluation methods, we can have more produc-
tive discussions about design and make more informed choices.
Throughout this book, each lens will introduce new tools for eval-
uation, moving us beyond gut feeling to more rigorous design de-
cisions.
8
Introduction
We make better decisions through iteration and feedback
No matter how many options we consider or how well we evalu-
ate them, we must submit our designs to the ultimate test of re-
ality. Most of our decisions will be suboptimal because we can’t
really hold the complexity of our soware in our heads.
You get better feedback by working directly in code, rather
than in another medium that needs to be translated to code later.
We make a choice, code it, and see what it looks like.
Working in code doesn’t mean building the entire system to try
out ideas. We can create lightweight approximations:
• Function signatures: names, arguments, and return types
as standins for fully implemented functions
• Stub implementations: e.g., using in-memory data struc-
tures instead of a database
• Prototype scenarios: to evaluate how well our model ex-
presses dierent use cases
These techniques let us directly understand the consequences of
our design decisions, while keeping iteration cost low.
Through these techniques (and more), we can gather more
feedback faster than if we had to build complete implementations.
Each iteration teaches us something about our design choices.
Making better soware design decisions
Soware design is fundamentally about making decisions under
uncertainty. To make better decisions, we need:
1. Better information: particularly from the domain itself
2. More options: seeing and considering alternatives
3. Systematic evalution: ways to compare options
4. Iteration and feedback: testing ideas against reality
In this book, you’ll learn specic techniques for extracting do-
main information, seeing alternatives, evaluating choices, and
getting rapid feedback. With these skills, you’ll be able to navi-
gate the complexity of soware design with greater condence
and eectiveness.
9Introduction
What are runnable specications?
Imagine completing your design process with a formal model of
your domain expressed in code—a highly expressive library that
represents any situation your soware needs to handle. Because
it maps cleanly to domain concepts, writing code that uses the
model feels natural. This is the ideal of runnable specications.
There are two main challenges to develop such a model: un-
derstanding the domain and encoding that understanding. In or-
der to face those challenges, this book focuses on three aspects:
modeling your domain in code, separating specication from
implementation, and seeking fast feedback. Together, these help
arrive at a model that ts our domain.
Modeling your domain in code
We encode an abstraction of the problem domain in code. Unlike
diagrams or natural language, code gives us a precise specica-
tion we can execute to compare its behavior to reality, helping
us understand both the model and the domain. And most of the
resulting code becomes the library you use in production.
Separating specication from implementation
When modeling in code, it’s tempting to slip into implementation
details like performance or storage. The power of domain mod-
eling comes from focusing on domain behavior. This separation
lets us explore design options without limiting our expressivity
with implementation decisions.
Seeking fast feedback
Because our model is executable, we can quickly test whether
it captures domain behavior and experiment with dierent de-
signs. We make conscious choices about how we write our speci-
cations to make the feedback faster and richer, accelerating our
learning and keeping the model honest.
These three aspects work togetherto arrive at a model that isn’t
just a specication—it becomes the actual library at the heart of
our soware. Throughout this book, we’ll explore techniques and
practices that help you apply these three aspects.
10
Introduction
This book is for programers growing from junior to senior
While senior engineers have found value in this book, I wrote it
for programmers on the cusp between junior and senior skill-lev-
el. If you are a good junior programmer, this book will help you
develop three key senior skills:
1. Reasoning about specications without implementation
2. Thinking holistically about systems in context
3. Exploring and developing system semantics
Reasoning about specications without implementation
As a junior programmer, I just wanted to start coding. But as I
matured, I learned to reason about how a system should work be-
fore implementation. Starting in Chapter 3, you will learn this
skill through function signatures.
Thinking holistically about systems in context
Junior programmers typically work on isolated tasks: add a fea-
ture, x a bug, make a button save data. As you grow, you start
to see the broader context—business concerns, long-term main-
tenance, and platform considerations. The chapters gradually
broaden this context, starting with data modeling and expanding
to business evolution, platform impacts, and problem denition.
Exploring and developing system semantics
When rst written, soware is oen seen as a set of features:
order coee, track the order, etc. However, as you add features,
you might realize the business isn’t just about coee. Perhaps the
coee shop is really about creating relationships with customers.
The programmers need to model customer preferences and per-
sonal details so baristas can have meaningful conversations with
regulars.
This is what I mean by semantics - understanding what your
system truly represents. A senior developer sees past surface fea-
tures to understand how the soware models and supports real
business relationships. I hope the skills in this book help you
reorganize how you think about programming in a deeper way.
about programming in a deeper way.
11Introduction
Functional programming is suited for domain modeling
We use the functional programming paradigm in this book. It is
very suited for the kind of modeling we will want to do. I wrote a
book on functional programming (Grokking Simplicity, published
by Manning). I recommend it if you want to go deeper. But for this
book, there are really only three big ideas that you’ll need.
Distinction between Actions, Calculations, and Data
Functional programmers distinguish three types of elements:
actions (functions and operators that have a side eect like send-
ing emails or modifying global variables), calculations (functions
and operators that merely compute and return values), and data
(non-runnable values). In this book, our models will be built al-
most entirely from calculations and data because we can reason
about them more easily than actions.
Data immutability
Functional programmers treat data as immutable, meaning you
don’t change it aer it is initialized. Although JavaScript vari-
ables, objects, and arrays are technically mutable, our code will
not modify them. Instead, we’ll make copies of data and modify
the copies to re-initialize them.
Higher-order functions
Functional programmers write and use functions that take other
functions as arguments. These are called higher-order functions.
JavaScript programmers will be familiar with these because any
function that takes a callback is higher order.
These three concepts are all you need to get started. Through-
out the book, we’ll learn some interesting FP modeling tech-
niques, including algebraic properties, property-based testing,
and reication. I’ve done my best to avoid advanced functional
programming concepts like monads and eect systems, instead
focusing on clarity of the example code so that the domain model
is evident.
12
Introduction
This book is organized into lenses
I’ve structured this book around the concept of lenses--dierent
perspectives for understanding and modeling domains. Each
lens oers its own insights, tools, and concepts, helping us un-
cover crucial details and translate them into code. Our ultimate
goal is comprehensive vision: seeing the full design space, from
programming language constraints to business needs, from user
requirements to platform limitations. The more of these ele-
ments you can consider simultaneously, the stronger your design
decisions become.
This approach brings inherent challenges. Many readers have
told me it feels unnatural to focus on a single aspect, like data
modeling, while setting aside related concerns like use cases. It’s
similar to learning graphic design--an eective poster is an in-
tegrated whole of color, contrast, typography, and space, and it
might feel strange to focus on just one element in isolation. This
discomfort reveals a core tension in learning complex skills:
how do we study the parts while knowing they’ll need to work
together? We can’t rely on simple principles, rules of thumb, and
patterns--beginners oen misapply them without recognizing
crucial exceptions. Nor can we follow a prescribed sequence of
steps, as real-world design decisions are too interconnected and
context-dependent.
The solution is to understand these lenses as learning tools
rather than strict guidelines. Just as a graphic designer might
rst master the principles of contrast, then explore color theo-
ry, then study spatial relationships--all while knowing these ele-
ments will ultimately work together--we’ll examine one perspec-
tive at a time. When you’re studying one lens and nd yourself
thinking “but what about...,” take note of that thought. We’ll like-
ly explore it through another lens. Rather than prescribing rules
or processes, I aim to help you see what was previously invisible.
You’ll learn what details to look for, how to evaluate what yound,
and how to capture those insights in code. The lenses provide the
tools and perspectives. You’ll learn to integrate them into your
design process with experience--just as a skilled graphic design-
er intuitively weaves together their knowledge of color, contrast,
and composition to create a unied whole.
13Introduction
Every complex part of your system can be a domain
When we began, I said that if you’re writing accounting soware,
your domain is accounting. This was a useful starting point, but
any signicant soware contains many domains worth model-
ing.
Consider a company making accounting soware as a service.
Many developers work on the accounting system, helping cus-
tomers track nances. But your team handles subscription pay-
ments - billing credit cards each month. Your domain is subscrip-
tion payments.
The payments domain contains distinct subdomains. One han-
dles monthly billing: calculating charges, processing payments,
and managing retries. Another manages subscription plans:
dening tiers and rules for upgrades. These interact at key mo-
ments--when a customer upgrades mid-month, the plan domain
tells the billing domain how to adjust charges.
The accounting and payments domains are separate but adja-
cent. They maintain their own concepts and rules.
Some domains cut across everything. A company-wide error
handling library creates a consistent model for reporting and
handling errors throughout all other domains.
Should you model every concern? No. Some are too simple.
The conguration library just stores key/value pairs in les--no
modeling needed. But if you added user permissions for modi-
fying settings, or dependencies between options, then modeling
might help.
How do you know when to model a domain? Look for these
signs:
• It’s vital to the business
• The code seems needlessly complicated
• Bugs appear frequently
• You need to standardize behavior across teams
Each sign suggests a level of complexity that domain modeling
can help tame. We’ll see examples of domains, subdomains, and
cross-cutting domains throughout the book.
14
Introduction
How does this compare with Unied Modeling Language?
Inevitably, when I mentioned the topic of this book during its
writing, people asked me how it compares to other paradigms.
This is a fair question. I might as well address it here and now to
help you contrast them and understand whether this book is for
you.
Unied Modeling Language (UML) is a visual modeling lan-
guage meant to aid in the soware design process. The creators
of UML wanted to present their design to stakeholders, many
of whom were non-programmers. Code contained too much in-
formation to understand at a glance, and the important design
decisions were intertwined with incidental implementation de-
cisions. So they developed a visual language to capture the main
design decisions without the extraneous details of the syntax of a
programming language. UML diagrams contain important char-
acteristics of the model.
UML is pictorial, while runnable specications use code as the
medium. Instead of using an intermediate modeling language
then translating it into code, in runnable specications we go
directly to code. However, we avoid the problem of having the
extraneous details because in runnable specications we choose
to use a very restricted subset of code. That subset is selected so
that we stay rmly in the specication (where important design
decisions are made) and out of the implementation (which is rife
with extraneous details).
But because we are writing the spec in code, we get several
advantages:
• There is no translation step, and no diagrams getting out of
sync with the code.
• We can solve many problems sooner because we can use the
tools we have for code such as type checkers.
• We can run the code and prototype the system to check if the
model does what we think it should.
The main thing we lose compared to UML is that it is not visual. It
is harder to read for non-programmers. We also risk slipping into
implementation inadvertently.
15Introduction
How does this compare with Domain Driven Design?
Another popular movement is the Domain Driven Design (DDD)
community which began with a book of the same name by Eric
Evans. In DDD, they design models in code, similar to in runna-
ble specications. In fact, I considered whether to make this a
Domain Driven Design book. But there are several important dif-
ferences that made me want to avoid the DDD branding.
First, the DDD book (and the surrounding community) are us-
ing the typical soware design principles, rules-of-thumb, and
patterns approach, which I don’t think works very well to teach
soware design. I’ve already mentioned why. I don’t want run-
nable specications to be assimilated into that, with the skills in
this book seen as patterns.
Second, the DDD book has a lot of project management advice,
and this book avoids that. Project management is important and
DDD probably has some great advice in it. But this book focuses
much more on the technical skills of soware design.
Third, DDD is mostly framed in object-oriented terms. That’s
ne, but I am framing runnable specications in functional pro-
gramming (FP) terms. I believe FP has unique advantages for
modeling (in particular, immutable data allows for better model-
ing of changes over time) and I want to highlight those.
Finally, this one is perhaps a little unfair, but it’s worth men-
tioning. The DDD book is a very large tome and contains a lot of
ideas and wisdom from Eric Evans. Unfortunately, it’s so big that
people can nd whatever they like. Two people discussing DDD
oen are discussing dierent subsets of ideas. So although they
belong to the same community, they oen don’t share much in
common. I didn’t want runnable specications to get lost in that
sea.
All of that said, I do think there is a lot of kinship between run-
nable specications and the ideas specic to modeling from DDD.
One might consider runnable specications to be a very practi-
cal guide to domain modeling that a DDD enthusiast might use to
teach others how to do it.
16
Introduction
How does this compare with soware design in general?
Runnable Specications is about soware design, so I should
place it in relation to the soware design movement in general.
Soware design is an important eld. We should be thinking
about the way our soware is constructed and try to optimize it.
However, I believe soware design has taken a wrong turn.
The main problem is that most soware design advice focuses
on the code artefact. That is, it uses code metrics to identify com-
plexity, code smells to nd trouble spots, and coding patterns to
prescribe how to make bad code better.
Now, to be clear, code quality is very important. I don’t want to
diminish the importance of it. But it’s not all there is. What about
the semantics of your code? Does your code correspond to the
thing it is supposed to do? It is as if we have a whole eld dedicat-
ed to style, but no eld dedicated to substance.
It is akin to giving a novelist writing advice but focusing only
on word choice, rhythm, and other stylistic concerns. What is
missing is the substance of the novel. What about plot, characters,
setting? Those are the things that make a novel worth reading;
style should support those. Analogously, soware design advice
should focus on being useful in the domain; style advice should
support it. What is the soware trying to do? What are the im-
portant facts we need to capture? How does the soware model
those facts so that the problem can be solved? Domain modeling
puts the content (the domain) rst. The style must support the
domain. Runnable specications focus our design decisions on
the information from the domain.
Further, soware design advocates oen talk about so-called
“non-functional requirements” as the goals of soware design,
particularly maintainability or readability. These are worthy
things to strive for, but in my opinion, the best way to get main-
tainable and readable code is to make sure your domain model
is good. A bad domain model begs for messy code that is hard to
modify. A good domain model makes readable code possible.
17Introduction
Runnable specications enhance the agile delivery cycle
Some might see domain modeling as big up-front design that con-
icts with agile development. But runnable specications oers
something dierent: executable models that help us understand
our domain while becoming the code we ship.
Domain modeling and agile development strengthen each oth-
er. The biggest design waste is modeling a feature the customers
never use. Agile cycles show us where to invest in modeling--we
start light when value is uncertain, then deepen our understand-
ing as features prove valuable. In return, good models accelerate
feature development by giving us a library to easily express do-
main behavior.
Runnable specications makes this practical through fast
feedback loops. You can test your understanding immediately
by running scenarios. You can explore domain behavior without
getting bogged down in implementation details. And because the
model becomes your production library, the investment pays o
directly in cleaner, more maintainable code.
The techniques in this book can help you spot and resolve de-
sign decisions earlier--like choosing between an array or hash
map based on domain constraints. While there’s always a bal-
ance between analysis and shipping features for customer feed-
back, as you learn skills in this book, be on the lookout for places
where they could help in your specic context. If you nd your-
self frequently revisiting certain types of decisions, the modeling
techniques here might help you move faster.
18
Introduction
How to use this book
There are three guiding points I’d like to make about how you can
best use this book.
Read the chapters straight through
I’ve written the chapters to be read in order. Some of them build
upon the previous ones, so they are not meant to be read inde-
pendently. They are also ordered to start with the most important
and fundamental skills and build from there.
Do the exercises
This book teaches practical skills, and to do that you need to get
some practice. To maximize what you get out of this book, do the
exercises before moving on. Each exercise has been designed
to practice what was just discussed in the text. And when you’re
done, you can compare against the answer. Since it’s code, there
is rarely a single correct answer, but it can help to see how some-
one else has done it.
Note that in the early release version (that you are reading now),
there are very few exercises. I will add more later as I get closer to
publication.
Use the supplements as reference
Some chapters are followed by supplements. You can read the
supplements as you get to them, but feel free to skim or skip them.
They are meant to be used as a reference for some of the material.
For instance, the Data Lens Supplement contains common rela-
tionship structures and lists how they are typically encoded.
19Introduction
Use this map to understand the journey through the lenses
The lenses in this book are a groups of related skills. I’ve ordered
them pedagogically, from the most fundamental to the least. If
you want to maximize the value per page, start from the begin-
ning. The lenses near the end, while very valuable, are less foun-
dational than the ones at the beginning.
The rst four lenses are about the build blocks of good models.
Data lens
Capture information and its relationships in a data model
Operations lens
Operations are the heart of a domain model
Composition lens
Capture how operations work together and ensure the exibility
your domain demands
Time lens
Model changes over time explicitly
The last four lenses are about concerns that aect our domains.
Domain lens
Dene the problem to model the right thing
Volatility lens
Look at how things change over time
Scope lens
Take a lateral approach to solving dicult problems
Platform lens
Build mini-models to isolate architectural complexity
20
Introduction
Conclusion
In this introduction, we understood soware design as making
decisions, and saw ways to improve our decision making. We also
learned about domain modeling, runnable specications, and
how they relate to other soware design methodologies. Finally,
we learned how to use the rest of the book. I hope this introduc-
tion convinces you to read the rest of the book.
Summary
• Soware design is about making design decisions. We make
better decisions with more information, by considering
more options, and with rich feedback.
• Domain modeling is soware design where the domain is
the main source of information for making design decisions.
The information from the domain is encoded as a model.
• Runnable specications is an approach to domain model-
ing that separates specication from implementation, mod-
els the domain in code, and seeks rich feedback. This book
teaches concepts and skills to do that.
• Runnable specications are dierent from Unied Modeling
Language, Domain Driven Design, and the soware design
movement in general, although they share some similari-
ties. I hope runnable specications contribute to the discus-
sion and the general skill of programmers.
• The skills of runnable specications are organized into lens-
es. Each lens provides a dierent perspective. With enough
perspectives, design decisions become easier.
• Read the chapters in order. Do the exercises. Skim the sup-
plements and use them for later reference.
Up next . . .
We’ve set the stage, now it’s time to get into the nitty gritty. We’ll
start with the data because that’s a skill we’ve all developed to an
extent. But we’ll use it as an entry point into using the domain as
the main source of information.