In this chapter, we briefly touched on the concepts of problem and solution spaces, requirements specifications, complexity, knowledge, and ignorance. Although at first, these topics don't seem to be directly related to software development, they have a significant impact on how and what we deliver.
Don't fall into the trap of thinking that you can deliver valuable solutions to your customers just by writing code and that you can deliver faster and better by typing more characters per second and writing cleaner code. Customers do not care about your code or how fast you type. They only care that your software solves their problems in a way that hasn't been done before. As Gojko Adžić wrote in his sweet little book about impact mapping (Impact Mapping: Making a Big Impact With Software Products and Projects, 2012, published by Provoking Thoughts), you cannot only formulate user stories like this:
- As a someone
- To do something
- I need to use some functionality
Your user, someone, might be already doing something by executing some functionality even without your software: using a pen and paper, using Excel, or using a system from one of your competitors. What you need to ensure is that you make a difference, make an impact. Your system will let people work faster, more efficiently, allow them to save money or even not to do this work at all if you completely automate it.
To build such software, you must understand the problems of your users. You need to crunch the domain knowledge, decrease the level of ignorance, accurately classify the problem's complexity, and try to avoid cognitive biases on the way to your goal. This is an essential part of DDD, although not all of these topics are covered in the original Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans, although known by the DDD community as the Blue Book.
In the next chapter, we will do a deep dive into the importance of language and discover the definition of Ubiquitous Language.