A vision for Runnable Specifications
An idealistic and practical take on domain modeling
If you want to watch me talk for two hours on the topic of my next book, Runnable Specifications, please check out my presentation to the Houston Functional Programming User Group. Two hours were recorded, but the conversation went on for four, it was such fun!
Speaking of my new book, I’ve published a major revision to the Introduction. It’s free to read online, along with the drafted parts of the book.
If you want to read my previous book, Grokking Simplicity, you can get it from Amazon or from Manning, or read it on O’Reilly Online.
A vision for Runnable Specifications
Imagine you are writing software for your construction equipment rental business. Imagine, further, that you have a library that completely, precisely, and simply captures the behavior of your business domain. That is, you can easily write expressions that represent every scenario possible in your business. Yes, there are millions of such scenarios, but you can tell by the way the operations fit together that there nothing could happen that you couldn’t describe.
You want to add a new feature to your point of service (POS) station. While the UI interactions are intricate, the business domain library makes anything you need to do easier. You are free to experiment with the UI because the library gets out of your way.
And then, one day, you notice that many people rent a Bobcat with their backhoe. You decided to add rental bundles to your business domain library. While it is a change to the business, you are able to keep the bundle domain rather decoupled from the rest of the business concepts. Rental bundles build on some ideas and compose others, while adding a couple of new ideas itself.
This is the vision for what I mean by runnable specifications. It’s an imperfect term. It doesn’t refer to the domain model per se. The specification is the program you write using the library. Essentially, you should be able to write a specification for how your business operates, then run the specification. Your library is the specification language. And because it’s written in your programming language, it is runnable.
Making it runnable has a number of advantages. First, you can easily prototype it. I’m so accustomed to programming with a REPL at my side that I can’t imagine wanting to work any other way.
Second, you might be able to ship it to production. A specification might not have all of the properties you need. For instance, it might not be performant enough to run under production load. But it might be! That would be the ideal case.
Third, even if it can’t ship to production, it could be used as a test oracle. Your specification defines how the business operates, so you could query it for what it should do in certain test scenarios. Compare that to the productionized code and you have a nice way to guarantee they both describe the same business.
Now, I said the domain model you write—that expressive library—is not the specification. It’s the specification language. However, that specification language was itself specified in code; its implementation is a specification itself.
The biggest problem with the vision of runnable specifications is that it’s a dream. In what world do we have the luxury of writing such perfect libraries? Certainly not in this one. But that’s the nice thing about this vision: even getting halfway there would be lovely.
Runnable Specifications (the book I’m writing) collects the skills I’ve learned over the years to help make those kinds of libraries. The libraries have a number of nice properties:
They’re built on total functions.
The functions compose well.
The functions tend to use the closure property.
And, of course, the functions tend to correspond to operations used in the domain.
I hope the book makes a contribution to the literature on software design. It already has the bulk of the material I’ll write for it (though revisions are often required). Please let me know what you think about the book. Just reply to this email.