Domain-driven development (DDD) is an approach to software design that focuses on the core domain and the logic that drives a business. The idea is to model the software based on real-world business concepts, ensuring that the code closely reflects the domain it is meant to serve.
Key aspects of DDD include:
-
Domain Model: A shared understanding of the business logic, defined in terms meaningful to domain experts and developers.
-
Ubiquitous Language: A common language shared by technical and non-technical stakeholders to describe the domain, ensuring clarity and reducing miscommunication.
-
Bounded Contexts: Distinct areas within a larger system where a specific domain model applies. Each context can evolve independently while being integrated with others.
-
Entities and Value Objects: Entities have unique identities, while value objects are immutable and are defined only by their properties.
-
Aggregates: Clusters of related objects treated as a unit, ensuring consistency in business operations.
-
Repositories and Services: Repositories handle data access, while services implement business operations that don’t belong to a single entity.
DDD emphasizes collaboration between developers and domain experts to ensure software design mirrors business processes and terminology.
A particularly important part of DDD is the notion of Strategic Design - how to organize large domains into a network of Bounded Contexts. [1]
Why is this important for your business?
The design it proposes puts our focus on the core domain and the business logic, which makes our product relevant and where it differentiates from competitors. The DDD design boosts the understanding of what our application does instead of which technology (framework, dependencies) it uses.
Domain-Driven Design is an approach to software development that centers the development on programming a domain model that has a rich understanding of the processes and rules of a domain. The name comes from a 2003 book by Eric Evans that describes the approach through a catalog of patterns. Since then a community of practitioners have further developed the ideas, spawning various other books and training courses. The approach is particularly suited to complex domains, where a lot of often-messy logic needs to be organized. [1]
We will see more about how this translates to our code as we understand the key aspects to be expanded in future posts.
Related:
[1] Domain-Driven Design by Martin Fowler
[2] Domain-Driven Design on Wikipedia