Ready for the future with Domain Driven Design

We believe in the Agile principles, where you develop software iteratively and make it better step by step. However, if you are dealing with complex workflows or an organisation with multiple business units, possibly operating in multiple geographic markets, it is better to get the basics right before you think about user stories and user experience. The solution? Domain driven design.

What is Domain Driven Design?

Domain Driven Design helps developing software that closely matches the business or an improved version of it. For this purpose, business experts and software developers describe work processes together, including all explicit and implicit rules and issues that characterize a business domain. This eventually leads to a conceptual description of a domain, with agreements on the terms used. This domain model is separate from the software (database and code), but it will often be used as a base for this. The domain model is also the foundation for further communication about the domain, such as setting requirements.

It starts with the business

Domain Driven Design is not so much a technical approach, but rather process-oriented. It all starts with listening to, discussing and understanding the way the business works or wants to work. The business and software developers need to understand each other, just like the employees within the organizations. By discussing the issues the business is dealing with, you get an unambiguous mutual understanding step by step.

Ubiquitous language

It is important that all employees, stakeholders, developers, project managers and so on use the same words for the same things. Therefore, you develop a language together that everyone understands and that everyone uses for the same purposes. This is called ubiquitous language. This leads to a conceptual scheme, containing all words specific to a certain domain and the description of entities and their relationships and rules. It is intended that ubiquitous language is used for all forms of communication (user stories, meetings, emails, technical documentation, planning, etc.).

From dictionary to code

The terms and definitions from the dictionary are being used in the code for the domain model. In this layer of the software you translate the business concepts and rules to entities, value objects, aggregates, behaviour, services, etc. Later, you are able to build the front-end solution on top of this layer. This way, the front-end solutions will be more consistent, stable and easier to maintain because of the way of working and the structure. Furthermore, all business rules are in one place, which is very useful is you want to change certain matters later.

Multiple models for bigger organizations

Larger organizations tend to have multiple domains. Even in this case, Domain Driven Design is easy to apply, since you can develop models for different domains within an organization. These models and developed applications then each have their own focus and language. In Domain Driven Design this is called “bounded context”. Next, you can integrate these applications externally and internally through API’s. This way, you make sure your applications fit the business domains they have to support.

When is DDD suitable

It goes without saying that it takes time and money to research how the business works. Domain Driven Design is useful if the business processes are complex or if they tend to become complex. Even when the business is expecting a lot of changes, but isn’t quite sure what kind of changes, you build a solid base for future solutions. In this case, the effort you deliver at the beginning of the process will pay back later. Software that doesn’t provide what the business wants or needs, or that doesn’t grow with changes, will cost more eventually.