In short, the book is about approaching your business as a franchise model. In this approach you're not only interested in building a single company, you're interested in creating a factory of businesses. More like McDonald's than a single shop. In this way of thinking, you're business becomes The Franchise Prototype.

While I'm still not yet sure if that's the way I'd like to run a business (it does smell a bit like corpo-stuff which I prefer to avoid), it did make me think about writing software.

When we're meant to work on a project, our focus is on the project. We want to get it done, the best way we can. We focus on the project and we try to avoid over-generalization, over-architectures and stuff.

What if instead of focusing on building the single project, you would focus on building a franchise of such apps? How would that change your approach? Would you do things differently?

In fact, that's what DHH did. He was meant to build a project management web app. What he actually built was Ruby on Rails, a framework for building web applications. Basecamp was just one instance of this framework (and it still is 10 years after that!).

What Domain-Driven Design taught me is the importance of tackling the business complexity by focusing on the right language - both in the communication with the business/clients/users and within the codebase.

What DHH did was actually creating the right language which is shared among web developers - controllers, actions, views, models, database, schema, migrations, resources. Everything else was a result of choosing the right language, a language which is shared by everyone.

In the business apps we work on, the target is not exactly developers (as in DHH case), it's the business and their customers. But developers are also part of the equation, they write the code using the language. If we do the job right, use the right business language in our code, then we might be able to build a factory of apps for this specific businesses, not just a single app. If we build the right abstractions, the creating new apps/features for the same business is similar to opening a new franchise instance - all easy, according to existing processes.

When you look at any franchise documents (as a developer you probably haven't had many chances), you'll see that those documents, those processes are organised around certain contexts - marketing, sales, finances, accounting, invoicing, recruitment. That's exactly what we call Bounded Contexts in DDD. A right definition of bounded contexts helps us create a consistent and repeatable description of the business we work for.