-
Notifications
You must be signed in to change notification settings - Fork 4
DDD Overview
Domain-Driven Design (DDD) is a software development methodology that focuses on building a deep understanding of the domain in which the software operates. It aims to create a shared language and model between developers and business stakeholders to improve communication, reduce complexity, and drive the design of the software.
The "domain" refers to the problem space that the software is intended to
address.
Example: In our project, the domain is the tracking of regions and
experiences.
A "ubiquitous language" is a shared vocabulary between developers and
non-developers.
Example: Terms like "Region," "Experience," and "User" are part of the
ubiquitous language in our project.
Entities are objects that have a distinct identity that runs through time and states. They are mutable and can undergo changes while maintaining their identity. Entities are the primary actors within the domain model and often have behavior associated with them.
Example: In our project, "User" and "Region" are entities. A "User" can change their profile information, and a "Region" can have new experiences added to it, but they still remain the same identifiable "User" and "Region."
Value objects are immutable objects that do not have a distinct identity. They are used to describe characteristics or attributes that belong to an entity but do not have identity themselves. Value objects are equal if all their attributes are equal.
Example: "VisitedRegion" and "CompletedExperience" are value objects in our project. These objects capture a user's interactions with regions and experiences but do not have an identity of their own. For instance, two " VisitedRegion" objects are considered equal if they represent the same region visited by the same user.
An aggregate is a cluster of domain objects that are treated as a single unit for data changes. Aggregates ensure consistency and integrity of data by encapsulating logic and rules that span multiple objects. Each aggregate has a root entity, known as the "aggregate root," through which all interactions with the aggregate should occur. The aggregate root is responsible for enforcing the invariants and business rules of the aggregate.
Example: In our project, "UserJourney" could be an aggregate that encapsulates a user's visited regions and completed experiences. The "User" entity could serve as the aggregate root, ensuring that the user can only mark a region as visited if it exists and can only mark an experience as completed if it is associated with a visited region.
Repositories are mechanisms for accessing entities and aggregates from the
underlying data storage.
Example: We might have a "RegionRepository" for accessing region data.
Domain events signify a change in the state of the domain that is meaningful to
domain experts.
Example: "RegionVisited" and "ExperienceCompleted" are domain events in our
system.
Domain services are operations that fall outside the boundaries of a single
entity or value object but are part of the domain model.
Example: A service to recommend experiences based on a user's past visited
regions could be a domain service.
Application services coordinate tasks and delegate work to domain objects.
Example: The service that handles user authentication and coordinates the
marking of regions as visited and experiences as completed.
Factories are responsible for creating complex objects and aggregates.
Example: A factory could be used to create a "UserJourney" aggregate from a
list of visited regions and completed experiences.
The content of this wiki is licensed under a Creative Commons Attribution-NonCommercial (CC BY-NC) License.