Have you ever used software that seemed completely out of touch with how your work actually gets done? Confusing terminology, endless menus, features nobody needs… these are signs of software that wasn’t designed with the real world in mind. Domain-Driven Design (DDD) offers a solution. It’s a powerful approach that aligns software with the way businesses truly operate. If you work at a company whose developers practice DDD you may have heard the terms ‘domain,’ ‘bounded context,’ and ‘aggregate’ floating around, let’s dive into what they actually mean.
What is a Domain
Simply put, a Domain is the specific business problem or sphere of knowledge the software addresses. Consider the following possible business types and domains that could exist within applications built for them:
- Finance : Bank Accounts, Clients, Transactions, Loans
- E-Commerce : Products, shopping carts, orders, shipping
- Human Resources : Employees, job postings, payroll
What is Technology
When we talk about technology, or Information Technology in particular, it often conjures images of computers, software, hardware, ect. Specifically a “Technology” is a tool to aid in a job, a shovel could be considered “hole digging technology”. So when we talk about Information Technology and take this same definition for the word, it pertains to Technology of managing, organising, and mining Information.
The purpose of technology, or in this case a software system, is to assist businesses to perform their functions. If we think about a bank account, at its core, it is a pot of money, a Bank could implement a bank account as a bucket of money, whenever you wanted to make a withdrawal, simply go to your bank, and have the clerk take the money from your individual bucket for you. A more efficient way of doing this could be to put everyone’s money in the same bucket and keep track of how much each person owns in a Ledger, this ledger would be a “Bank Account Technology”.
Conway’s Law
In Computer programming, Melvin Conway is quoted as saying
Organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.
Simply put, Software designed for a business should mirror the business.
Why Domains matter
When building software, you’re not just writing lines of code; you’re creating a Technology, a digital representation of something that exists in the real world. The better that model matches the real-world domain, the easier it is to make the software work the way users expect and need.
This is where things can get tricky. Software developers speak the language of code. People working in healthcare, Human Resources, or finance speak the language of their domains. These languages can seem worlds apart! DDD helps bridge that gap.
Core ideas of Domain-Driven design
At the core of DDD there are the following tenants:
- Nothing is more important than the domain : The most important thing is fully understanding the domain where your software will live. DDD encourages developers to spend time talking with the experts – the doctors, the Bankers, the HR managers – to get inside their heads and understand their portion of the business.
- Ubiquitous Language : DDD wants developers and the domain experts using the same words for the same things. If the experts call it a “patient chart,” that’s what it’s called in the code too, leading to clearer communication.
- The Code Reflects Reality : The goal is to create software that matches the core tenants of what it is replacing. This makes the software easier to understand, maintain, and change as needs evolve in the business.
Ubiquitous Language
Imagine trying to use an online banking system where your account is called a ‘client profile’, transactions are listed as ‘modifications’, and getting a loan requires filling out an ‘asset acquisition form’. Confusing, right? This is what can happen when software doesn’t reflect the way people actually talk about their work. Domain-Driven Design (DDD) is a powerful approach to software development that helps make sure software actually solves the problems it’s meant to address
Building Blocks of Domain-Driven design
Some of the concepts used in DDD are :
- Entities : A “thing” in your domain like a Bank Account, or Shopping Cart, or Employee. These are modeled after the real world item and will contain the important information about said thing.
- Aggregates : A collection of Related entities that are treated like a single unit. As an example the Aggregate of Bank Account could have a child Entity of Ledger.
- Bounded Contexts : A Bounded Context is a logical grouping of Aggregates used in larger projects. Each Bounded Context can have its own Ubiquitous Language and allow the system to be divided into more manageable sections.
Benefits of Domain-Driven Design
- Bringing developers closer to the business: The collaborative nature of DDD improves communication between developers and domain experts, leading to better solutions overall.
- Flexibility : As DDD focuses on a deep understanding of the domain, when changes inevitably happen in the real world the software is inherently easier to change as it was designed with a better understanding of the real world problem that it is trying to fix.
- Team Communication : With ubiquitous language at its core, both developers and non-technical staff are talking the same language there is often less miscommunication.
Domain-Driven Design (DDD) is a powerful tool for modeling and implementing software solutions in complex business domains. By focusing on a deep understanding of the domain, its language, and its core processes, DDD helps bridge the gap between business experts and software developers. This results in software that is more intuitive, adaptable, and truly aligned with the problems it’s designed to solve.