A brief introduction to Domain-Driven Design

Introduction

To develop high-quality software, you have to know what that software is about. You cannot create a banking software system unless you have a good understanding of what banking is all about.

It's not the software architect or the agile coach who knows about banking.

The banking system is well understood by the people inside, by the bankers. They know all the details, all the catches, all the possible issues and all the rules.

This is where we should start: the domain.

Building Domain Knowledge

Domain-Driven Design is to make software a reflection of the domain. Software needs to incorporate the core concepts and elements of the domain and accurately represent the relationships between them. The software has to model the domain.

If you’re working in an organisation with any kind of process, you likely have requirements expressed as a user story, task, or use case. These requirements or specifications you receive are usually incomplete.

Typically requirements are somewhat murky or expressed at a high level of understanding. In the course of designing and implementing a solution, it is beneficial when developers have access to the people who bring some…