In this episode, I introduce the stratified design lens, which talks about how and why we split things into layers.

In this episode, I introduce the time lens, and I posit a law about representing time in complex domains.

In this episode, I introduce the volatility lens, which seeks to help us write code that deals with a changing world.

In this episode, I introduce the architecture lens, its questions, and its goal of modeling architectural domains to manage complexity.

In this episode, I introduce the executable specification lens, its questions, and its goal of getting to runnable, testable code as quickly as possible.

In this episode, I introduce the composition lens, its questions, and its goal of figuring what's true when you perform multiple operations in a row.

In this episode, I introduce the operation lens, its questions, and its goal of capturing the use cases of your software.

In this episode, I introduce the data lens, its questions, and its goals of capturing relationships among data values in data.

In this episode, I introduce the domain lens, its questions, and its goal.

In this episode, I compare executable specifications to UML, DDD, and software design.

I've found a better title for my book: Executable Specifications. Listen to find out why it's better.

I'm organizing my new book in terms of lenses. Each lens focuses our attention on one important aspect of software design. In this episode, I briefly introduce each lens.

I talk about the progress I've made on my book and why I'm throwing it away and starting over.

I give another reason why I don't encounter so many type errors in Clojure.

Watch the creation of a simple refactoring to turn functions into data.

One important skill in domain modeling is learning to see the semantics of your language, past the habits you've developed. To do that, it helps to see the same example in multiple languages. So how do I show examples in multiple languages without expanding the size of my book?

An isomorphism is a one-to-one mapping from two sets, and encoding your domain model involves finding a mapping between the real world and your code. So does domain modeling involve isomorphism?

Domain modeling also works after you've already got lots of code. How can we apply domain modeling analysis to existing data structures?

We discuss the commutative property, why we use it, and three different possible meanings.

We look at several examples where the associative property gives us expressive power.

We describe a three-step process for discovering conceptual models.

I discuss the closure property, which creates operations that can be nested. It's one thing that makes an API feel like a DSL.

What do I mean by algebra? And how do we get from level 0 to level 3?

All sophisticated models need to include time. We discuss two main ways to do that.