Domain-Driven Design was conceived for custom solutions for the enterprise. While many of the ideas still apply, developing software in the product space poses a new set of challenges: coping with uncertainty on backlog and strategy, managing the different sources of feedback and stepping up to protect design integrity against the many forces pulling in different directions.

Some companies are going "full DevOps" and apparently releasing at the speed of light. Other companies are still struggling with estimations and slowly thinking about going microservices. Other are happy with their monolith, but struggling with recruiting.

We’re all developers, but we’re not doing the same job. The line connecting a problem to its solution is relatively straight in some organizations and incredibly convoluted in some hours.

Processes, Software architectures and Organization are not separate concerns, neither are orthogonal. Pretending to fix one thing without touching others is a losing battle.

We’re part of the problem. Our software is part of the problem. We can be part of the solution too.

Since the early days, software development has evolved a lot. Writing code used to be a long tiring activity, but now is no longer the bottleneck. However, if we see software development with a different perspective, we'll realize that there are vast opportunities for improvement, by switching to a more appropriate metaphor.

How big picture modelling can lead to better software and better companies too.

Traditional requirements gathering and modelling is broken. A simple recipe - bring all the key stakeholders in the same room and build a model of the whole business process, starting from Domain Events, collaboratively - led us to unexpected discoveries and better software too.