The word ‘product’ is everywhere these days. There are so many different definitions out there, that is getting confusing. There is this belief in the software community that, in order to build good software systems, everything needs to be a product. That this is the best way to deliver value to your customers and that projects are no longer useful in the context of software development. But is this really true?

In this talk, I will explain my understanding of what a product is and what it isn’t in the context of software development. I will introduce a new concept called ‘streamlet’ and explain how it can help you with thinking in products and teams. I will clarify how Domain-Driven Design helps you with product vs project decisions.

From Parnas' paper in the 1970's to microservices in the 2010's, we've always used modularisation as a way to manage complexity in software. And yet, we still end up with big balls of mud. Perhaps technical separation isn’t cutting it. We’ve also tried separating into business domains, but that’s not enough either: software wants to be deeply interconnected, spanning different domains, and doesn’t respect those boundaries.

Bounded Contexts provide an alternative. We can separate semantically, looking at the domain models that underlie our systems, the language being used, and the meanings of terms. We can draw “understandability boundaries”: separations that look at how concepts in our system are understood together (or can be understood autonomously). If we organise the teams along the same lines, they need to understand fewer concepts to be productive, they lower cognitive load, and need less coordination with other teams.

Doing this kind of work is not free. But in the 20 years since the concept was introduced in Domain-Driven Design, we’ve developed patterns and heuristics to guide us.