What is the title of my new book?
This is an episode of The Eric Normand Podcast.
Subscribe: RSSApple PodcastsGoogle PlayOvercast
I've found a better title for my book: Executable Specifications. Listen to find out why it's better.
Transcript
[00:00:00] What is the title of my new book?
[00:00:02] Hello, my name is Eric Normand and this is my podcast. Welcome.
[00:00:08] I have been calling my book Domain Modeling. I've always considered it a working title.
[00:00:19] I think it's maybe too broad because I'm not exhaustively giving the treaties on all possible domain modeling approaches. It's not right. But I haven't really been able to find the right title until maybe now.
[00:00:46] You'll have to wait a little bit. I'll give you the title in this episode, don't worry. But I have been going through a reorganization of the material and really trying to rethink what the book is for and what you can learn from it. What are the benefits of the book? And I wrote up something and sent it to someone I trust to, to give me comments.
[00:01:22] And the comments I got were that this is just what every software design book claims, what I had written was: easier to maintain software, easier to write, cheaper to write, easier to read, you know, more flexible, things like that. And I do believe that domain modeling helps with that. But I also think that I need to be maybe a little bolder and less benefity.
[00:01:56] So, yes, at the end of the day, everyone wants cheap to maintain software, so that's what you wanna sell. Except nowadays, everyone has been sold on this idea of cheap or maintainable software, and We don't believe it. We've been jaded by this selling. I mean, it's kind of like if you're trying to sell a shampoo that makes your hair always beautiful or a shampoo that works for everybody, something like that.
[00:02:34] People are gonna want to know how exactly is this gonna make my hair better? I can't just have beautiful hair, like I want a certain kind of beautiful hair, right? I know I need to control my curls, right? Or my hair breaks really easily, or my hair is very thin and wispy. And so everyone has different hair problems and so you need to actually sell them the solution to their particular hair problems.
[00:03:11] I've been racking my brain about what it is that I'm selling and why. I have a little paragraph here. In this book, we will learn an iterative and fun approach to software design that leads to flexible expressive code.
[00:03:32] So I've got four things in there: iterative and fun, flexible and expressive. That's it. I think that that kind of captures what I'm trying to do with this book. If you don't care about fun, maybe this book is not for you. If you don't want expressive code, this book is not for you. Right. I mean, other books are gonna claim to be able to help you develop your code on time and on budget and that sounds really nice.
[00:04:19] But I don't think I can do that. I don't think that's what I'm trying to sell right now. I started thinking, well, domain modeling doesn't really give you the iterative and fun, and it doesn't give you the flexible or expressive code. But what does, it's the executable specifications.
[00:04:42] So executable specifications, title. Subtitle: an iterative approach to domain modeling.
[00:04:52] Domain modeling means encoding your understanding of a problem domain separately from your implementation of the solution, separating the two out.
[00:05:03] But then in my book, it's a subset of domain modeling where we build executable specifications. The domain model is a module written in the implementation language of your software instead of some other modeling specific language like UML.
[00:05:23] And the idea is that we design our domain model in such a way that we can write a specification in code and then we run it. So the specification is just stating the problem we would like to solve and we run it, and that's our solution.
[00:05:45] And the iterative is that because your domain model is in code, and you can test it, you can run it. You can build a little scenario like this person wants to order this pizza. So they're gonna go through these actions in the domain, and you code it up, and then you run it and you see if it works and if it doesn't work.
[00:06:15] You're not just debugging your code, you're debugging your understanding of the domain, which is the model. And so then this is giving you lovely fast feedback to help you build better understanding of your model. It's an approach to modeling almost entirely about this feedback loop.
[00:06:44] I say almost entirely cause we also have all the lenses that are asking you questions and helping you sort through all the bits of your domain that you need to understand. But this is the approach that gives it the power, that makes it fun and iterative. And it's expressive because, well, we've got the lenses and it's flexible because of the scoping and layers.
[00:07:14] And so it's all there.
[00:07:16] My name is Eric Normand. This has been another episode of my podcast. Thank you for listening, and as always, rock on!