Every day, we write software that solves business problems. How we actually do that is largely up to us. We tend to build models that encapsulate complexity and provide abstractions that help us reason about the problems we solve.
We stress our models with incremental development. Changing business requirements challenge the durability of our models. The magnitude of change is an indicator for the effectiveness of our models' ability to represent the problem domain.
At Which? we used Domain Driven Design to deliver our most recent project. In this talk, I will share those insights. I aim to cut through the jargon and give concrete, real-world examples of how we applied the principles of DDD to build a product that anticipates change.