Domain Driven Design: Introduction
Domain Driven Design, or DDD, is a software design approach that emphasizes solving business problems and organizing the corresponding logic, rather than focusing on details such as programming languages or infrastructure technologies. The primary goal of DDD is to map real-world systems or processes into software artifacts. In order to enhance our comprehension of the fundamentals of DDD, let's take a closer look at some crucial concepts.
Domain Driven Design
What is domain?
In the context of DDD, the term domain typically refers to the business logic and rules. When applying DDD, it's important to collaborate closely with a domain expert who can provide insights into how the real-world system functions. In other words, it's crucial to communicate with individuals in the businesses where you're addressing issues and comprehend their perspectives before proceeding.
What is ubiquitous language?
Between yourself and the domain experts, you build a ubiquitous language (UL), which is a common set of terms and definitions used by the entire team, both technical and nontechnical. The idea is that you should be able to write down what the system does in a way that the domain expert can read it and verify that it is correct.
What is bounded context?
Bounded Contexts are used to manage large domain models by dividing them into distinct sections. This approach groups similar components and concepts minimizing confusion and ambiguity that might arise when dealing with similar terms without a clear context.
What is an aggregate?
An essential pattern in DDD is the Aggregate. It involves grouping a set of domain objects together as a single unit. One of these component objects within the Aggregate is designated as the Aggregate Root, to which any references from external sources must point. The primary objective of Aggregates is to establish consistency boundaries and enforce invariants within the domain model.
Domain Driven Design provides a powerful framework for developing robust and effective software systems that are better suited to solve real-world business problems. In upcoming posts we will review DDD layers, elements, patterns, as well as best practices.