Many products start out with a simple, naive model able to prove market fit. And most of the time that one model grows, because more features need to be put in at a fast pace. This can have a huge impact once the product needs to scale. Because that fast pace can turn the model into a Big Ball of Mud, and most of the time that model isn’t the most useful model to solve the core business problems anymore. Everyone in the team knows we need to change that Big Ball of Mud, but we also don’t want to close shop. We want to keep adding features to attract more customers, scale the product and turn into a profitable product. So how can we both get ourselves out of the Big Ball of Mud while also scaling the product?
In this talk, I will tell the story of how our software development team decoupled their Big Ball of Mud, to several bounded contexts all within the same monolith. I present several heuristics, practices, tools and a strategy to decouple the current model while continuously adding features to the product and gaining feedback from the customers. One of the bigger challenges was that the team had no knowledge of Domain-Driven Design, and I will show you how the team with their stakeholders started embracing DDD. Ending up with a strategy to disentangle the model, an idealised bounded context design and monitoring domain events from the bounded context that drove collaboratively drives the product roadmap.
Outline of the session:
- Introduction of the use case, it’s domain and the challenge
- Domain-Driven Design 101
- Why understanding the underlying needs was crucial
- Collaborative software design and embedding software architecture in the teams
- From output to data-driven outcomes through Domain-Driven Design