Introduction To Domain-Driven Design
However, these factors are not the only considerations when designing software to meet our business objectives and justify its use in production.
Since I started working as a software developer, I've found Domain-Driven Design to be one of the most challenging topics in every project and company I've been a part of. It's not just difficult during the development phase, but also during the architectural planning and decision-making stages.
Nowadays, Domain-Driven Design is an inevitable subject in software production procedure and underestimating or eliminating this concept from software delivery life-cycle and generally from companies' workflow can be costly and may even lead to project failure.
In this series of articles, including this one, Strategic Domain-Driven Design, and Tactical Domain-Driven Design, I'll happily share my knowledge, experiences, and lessons learned about Domain-Driven Design in software engineering and development.
I'll explain why Domain-Driven Design is necessary and we'll learn how it can help us achieve better outcomes and greater success for our company.
What is Domain-Driven Design?
Domain-Driven Design is a set of tools that helps organizations (architects, developers and domain experts) to design a high-quality software. In other words, Domain-Driven Design is a software development approach that guides us to not to repeat our failures in designing software by putting the “Effective communication” between parties as the core principle.
Domain-Driven Design is not first and foremost about the technology. In its most central principles, DDD is about discussion, listening, understanding, discovery and business value, all in an effort to centralized knowledge. -- Vaughn Vernon, Implementing Domain-Driven Design
You might wonder which projects need Domain-Driven Design. As a matter of fact, DDD is often considered an expensive and overly complicated methodology if not used correctly, for various reasons. To answer this, let's look at DDD in terms of cost and complexity:
Successfully applying Domain-Driven Design requires expertise in two critical areas that are both costly and scarce in the job market. First, you need someone who deeply understands the business domain, often referred to as a domain expert. Second, you need technical experts who can collaborate effectively with domain experts.
Domain-Driven Design is a solution to model complex business domains directly in the software which can lead to intricate domain models. Therefore, it can simply increase development complexity, production cost and time to market as well.
Collaboration between stakeholders, such as architects, developers, domain experts and even marketing team, is crucial for effective Domain-Driven Design. To achieve this, we need to establish different and unique forms of communication style between parties, which might add overhead.
We can't implement Domain-Driven Design easily without providing proper infrastructure and/or tools. Specifically, to support and implement complex business models, we need tools like Miro Board and the infrastructure for conducting EventStorming workshops. These resources are essential and come with costs.
So, we should carefully consider the costs associated with implementing Domain-Driven Design and assess whether it will truly benefit our project. By taking these factors into account when adopting DDD, we streamline our project's solution.
Domain-Driven Design Categories
To accept and implement DDD methodology, we should be eager to improve the software and have skills to explore design alternatives using proven agile methodologies. Domain-Driven Design can be categorized in two main groups:
Strategic Domain-Driven Design which fulfils the specific constraints and particular requirements of business domain.
Tactical Domain-Driven Design that describes how to put the business in action and apply it in practice.
Domain which is the software is designed to address, encompassing the business logic and requirements.
Model is a simplified version of a domain that highlights the key elements important to solving a specific problem. A well-designed model should mirror the language and concepts familiar to domain experts.
To meet the business needs effectively, each assembled domain model should be mapped to the technical architecture (frameworks, programming languages, …).
Strategic Domain-Driven Design
Strategic Domain-Driven Design is a software development method that prioritizes understanding and modeling the main domain and its associated logic. It highlights the importance of collaboration between domain experts and developers to ensure the software accurately meets business needs and requirements. The strategic element of Domain-Driven Design offers guidance on how to organize the software system, define its boundaries, and create a shared language among all stakeholders.
Below is a brief overview of Strategic Domain-Driven Design parts. To have a comprehensive understanding about it, take look at Strategic Domain-Driven Design. In that section, I will explore these topics in more detail.
Ubiquitous Language: The common language used by all parties to communicate with to avoid making assumptions about business requirements and to clear all possible ambiguities.
Bounded Context: The ubiquitous language should be divided into smaller, context-specific languages that are only relevant within certain boundaries. This boundary is known as a Bounded Context, which outlines the scope within which the ubiquitous language is applicable.
Context Map: Relationship and pattern between bounded context which could be partnership, shared kernel, conformist, anti-corruption layer and open-host service pattern.
Domain Analysis - Core Subdomain: The most complex business domain which should be developed and maintained in firms by in-house developers.
Domain Analysis - Supporting Subdomain: The simplest business domains that act as supporter for core domain.
Domain Analysis - Generic Subdomain: The solution that every company use in the same way and don't have any competitive advantages.
Tactical Domain-Driven Design
Tactical Domain-Driven Design offers practical methods and tools to implement DDD effectively by introducing the following key concepts and it provides a set of techniques that help bring clarity and structure to complex systems. These tools are particularly useful for creating well-defined, maintainable, and scalable code.
Below is a brief overview of Tactical DDD parts. To have a comprehensive understanding about it, take look at Tactical Domain-Driven Design. In that section, I will explore these topics in more detail.
Architectural Pattern - Domain Model: It consists of three patterns: Value Object, which is defined by its values, meaning its identity is shaped by the attributes it holds; and Aggregate, which represents a collection of entities and value objects that are grouped together in a cohesive cluster, often treated as a single unit in the domain model. Entities, on the other hand, are objects that have a distinct and explicit identity.
Architectural Pattern - Transaction Script: This pattern divides the business logic into procedures or transactional behavior for such ETL.
Architectural Pattern - Active Records: The functionality of active records is the same as transaction script but for more complex processes like CRUD.
Bounded Context Architecture: It describes methodologies to define communication paradigm between components inside bounded context.
Bounded Context's communication architecture that can be categorized into two main styles of information transmission: Synchronous Communication, where the exchange of information happens in real-time, with both parties needing to be available at the same moment, and Asynchronous Communication, where the information exchange occurs without requiring immediate response or simultaneous availability.
Wrapping Up
Domain-Driven Design is a software design approach that focuses on understanding the core business domain. it divides its practices into two main categories: strategic and tactical.
Strategic DDD deals with the high-level architecture and design of the system. It involves concepts like Bounded Contexts, Ubiquitous Language and Context Mapping. These concepts help ensure that the software structure aligns well with the business structure, improving clarity and scalability.
On the other hand, Tactical DDD focuses on the detailed implementation of domain models within these contexts. It includes patterns like Entities, Value Objects and Aggregates.
Together, Strategic Domain-Driven Design and Tactical Domain-Driven Design offer a comprehensive framework for building complex software systems closely aligned with real-world business needs and offer strong competitive advantages.
Share This Article