Domain-driven design (DDD) is a software development approach that tames the development of complex applications. It is a technological/organizational pattern used to solve problems on a specific project. If performed correctly, DDD results in a better and more flexible code that simplifies the addition of new functionalities and advancements of existing software.
Domain-driven design establishes a communication channel between a developer (or an entire team) with one or more domain experts. The idea is to provide the dev team with the means to build a domain model everyone involved in the project would understand - developers, domain experts, managers, and others. This model should accurately explain the problem that the new software is intended to solve.
So the term domain in software development circles refers to the subject area for which the software is built. And domain-driven design is a practical approach to problem-solving through code that serves as an answer to complex software development projects.
Domain-driven design revolves around three core principles:
The first step to building a domain-specific application is to get well-informed about it. This involves conversing with people and experts who work in that domain to learn the terminology and better understand how different processes work. In other words, if you’re looking to build an application for a pharmacy, you need to know all about their products and services, how they interact with customers, and which aspects of their business they are looking to redefine with the new software.
Your second step should involve building a domain model that will be an accurate reflection of the real-world domain. And your model will be anything you want it to be: a paragraph, chart, or a diagram, as long as it represents the domain and the product you are building to meet the requirements.
Now, to build a domain model, developers use ubiquitous language, i.e. common language built to unite all people on the project and prevent miscommunication. It enables the creation of a highly comprehensible model that simplifies the development of complex projects.
Domain-driven design requires constant refactoring each time a team uncovers something new about the domain. Refactoring helps write cohesive and maintainable code, which makes it an essential development skill.
There are three fundamental layers of a domain-driven design:
Simply put, the application layer is a use case layer. It doesn’t contain domain-related logic but solely serves to organize domain objects and ensure they successfully complete their role. The application layer is thin, as it doesn’t contain any business logic. Its key role is to coordinate tasks and delegate work to collaborations of domain objects in the next layer.
This layer is a central part of the business application, kept separate and independent of the other two layers. It contains the entire domain logic, stores all information about the business rules and all entities, that is, the combination of data and behavior (user or product).
The domain layer also contains services that are available to software users. As such, they are written in a ubiquitous language using simple domain-related terms that are familiar to target customers.
The infrastructure layer enables communication between the other two layers. It also serves as a storage space for any supporting libraries that are necessary to run the user interface layer efficiently.
The easily-accessible and universal language of the design model eases the communication between developers working on the project. Ubiquitous language successfully bridges the gap between the dev and business team. It helps them learn from one another, easily align their goals, and ultimately avoid any miscommunication issues.
What is specific about the code written as a result of the DDD approach is that it tells a story everyone working on the project can understand, even those without any coding skills. As such, the code can be easily modified and extended.
The existence of the domain layer encapsulates all business rules, containing them rather than allowing them to be scattered across the code. This makes the rules far easier to read and comprehend by the people who work on that code.
The domain layer is extremely stable, as the changes are made only when the requirements change. As mentioned above, it is completely independent, which makes it easily applicable to other projects. Finally, it prevents inaccurate use of domain terms, since all states and transitions occur just as they would in real life.
To succeed, one person in the team needs to create a common model and language to allow business and development teams to communicate and understand the nature of the problem. In addition to exceptional development and coding skills, this person has to possess the knowledge of DDD, which is why this role is commonly outsourced.
Domain-driven design comes with various rules and conventions that need to be followed, which doesn’t always make sense for smaller, less complex projects. In such cases, DDD is nothing more but unnecessarily time-consuming.
Domain-driven design isn’t practical for apps with minimal domain complexity. However, it is also ill-suited for highly technical projects. Due to the intricacy of the project, domain experts and the business team may find themselves in a situation where they cannot deal with technical requirements or limitations, simply because they don’t understand them.
Mastering domain-specific knowledge is as crucial as mastering any technical skills. It allows developers to contribute to a long-term vision of the company they work for.
Here at Inviggo, we’ve experienced first-hand just how essential domain-specific expertise can be to the success of the entire project. It helps developers better understand:
Remember that before even thinking about specializing in a certain domain, developers have to perfect their coding expertise. These allow them to first combat some simpler and/or generic challenges which they later use as a foundation for any domain-specific questions. Once they gain confidence, they can think about gradually tackling the domain they are most interested in and build much-needed, cutting-edge software and applications.
You need to:
This isn’t something that will happen overnight. The more time you spend with the team working on one and the same subject matter, the more you will understand the ins and outs of the domain. To build truly valuable experiences, a developer has to look at the bigger picture and try to understand the system in its entirety.
To better grasp the context of the domain, developers are often advised to test the 5-Whys technique which, as its name suggests, entails asking “why” 5 times. This iterative interrogative technique helps uncover not-so-evident problems and root causes of specific problems. The fact is – the more questions you ask, the more you learn about a domain, and the better you become at mastering its secrets.
Seeing as how we’ve emphasized the importance of experience, a logical step would involve working closely with a senior developer. Look up to their work, pick their brain whenever you get a chance, and get as much feedback as possible regarding various aspects of the project.
At Inviggo, we strive to improve our skills and expertise in healthcare and telehealth fields. These truly require experience and specialized knowledge of the struggles that prevent people from receiving medical assistance.
Over the years, we’ve worked on healthcare web applications that connect medical professionals with patients who need efficient remote assistance; a digital pharmacy solution to automate manual processes and simplify prescription management; a mental health application to offer therapeutical assistance to everyone, at all times – and that’s just the tip of the iceberg.
All these projects gave us insight into the greatest limitations of traditional healthcare services. Not only that, but we also came to realize just how crucial web accessibility is for creating applications that will be, well, accessible to absolutely everyone, regardless of their temporary or permanent disabilities.
Our developers are ready to get to grips with any new telehealth challenges you might bring upon us.
So – got any innovative ideas we can help you with?
