When developing software, it is all too easy to get caught up in the details of implementation, without ever getting to the bottom of the problem. As software developers, our main goal is always to add value to the business, and for this to work, we first need to be clear what the problem we are trying to solve is. This has been attacked in several ways throughout the history of computer science. Structured programming gave the developers a way to break a problem into pieces, object-orientation attached those pieces to named things that allow for further structure and better associate meaning with parts of the program.
Domain-driven designs focus on getting structure in the problem solving process and also provide the right starting point to begin a conversation every stakeholder can be part of. Language is an important part in this, since communication is an area where a lot of projects struggle, as there often is a mismatch between engineering and business. While engineering terms are often more specific, the business language leaves room for interpretation, leaving it up to the person and his or her context to resolve what has been talked about. Both forms of languages have their place, as they have been established as an effective form of communication in their specific scenario, but translating between these two is often where problems or bugs are introduced. To help with these problems, domain-driven design allows a developer to classify certain types of object in the communication in several forms, all of which are going to be introduced in detail throughout this book:
Value objects
Entities
Aggregates
Bounded context
These are concepts that have a certain meaning and allow classification objects, which are part of a business process. With this, we can attach meanings and patterns.
Considering the different ways to create a program, the main improvement that structured programming added to the way we program today is the idea that while working on a project, the programmer does not always have to have the whole project in his head to make sure to not duplicate functionality or interfere with the regular flow of the program. This is accomplished by encapsulating functionality in chunks to be reusable in other parts. Moving onward, object-oriented programming added the ability to further encapsulate functionality in objects, keeping data and functions together as one logical unit. One can say a similar thing for functional programming, which allows the programmer to think about his program as a flow of functions that are defined by their input and therefore can be composed as larger units. Domain-driven design now adds a layer on top, which adds abstractions to express business logic and can encapsulate it from the outside interaction. Creating a business layer that interacts with the outside world via a clearly defined API does this in this case.
Looking at these different practices, one thing shines through on all levels, and this is the idea of removing distractions. When working on a large codebase or on a complex problem, the more you have to keep in your head at once, the higher the level of distraction from the core problem. This is a major point of domain-driven design, and we are going to see how this plays out in the next chapter when we think about how we can go from a specification that we have seen before, toward a problem description we can continue to work with.
In a lot of cases, stating the problem is actually not obvious. This is why working towards a shared understanding between business experts and developers is so important, both sides need to agree on what they expect from a feature, or a piece of software. Allowing developers to state in clear terms to the business what the feature solves allows the developers to focus on the problem at hand and get input more directly. Similar to the principles of test-driven or behavior-driven development, stating in a clear fashion what something is intended to do helps the development a long way. At this stage, creating a route to get from A to be B as well as objectively stating when a goal has been reached, is what we seek. This by no means saves us from reconfirming that the goal is still the one to achieve constantly with the business, but it allows us to make this communication clear. With the language established, this now does not have to involve multiple hour-long meetings with no clear outcome.
With all this in mind, it is now time to dive into the essence of domain-driven design. Throughout this book, we are going to move our orc dungeon to the 21st century, allowing it to flexibly adjust to its business needs. As a first step, we are going to sit down and see what running this dungeon is all about and how our new software can add value using the concepts and the mindset of domain-driven design.