What is Domain Driven Design?
Domain Driven Design is an approach to develop software applications that centres the business domain at the core of the development.
The domain that the software is developed for stablishes the naming convention and concepts that should be used when defining classes, interfaces and data models. A business domain can be anything: health, insurance, economy, advertisement, …
The main benefit of using Domain Driven Design is to avoid messy terminology which lead to confusing systems. The use of Domain Driven Design concepts ensures that the software is developed to satisfy the needs of a business domain and not the other way around.
Collaboration with domain experts is key when developing a software system in Domain Driven Design. That allows for accurate data models that enhances the object-oriented mapping of an application.
The origin of Domain Driven Design is a book publish on 2003 by Eric Evans which stablishes the base for developing using DDD ideas. Since then, a community of software engineers has contributed to improve the ideas and concepts behind Domain Driven Design.
One of the key ideas when implementing Domain Driven Design is the need to build a Ubiquitous Language that introduces the domain terminology into the software application that is been developed.
Domain Driven Design: Ubiquitous Language
When developing a software application using Domain Driven Design it is required to stablish a base language that covers concepts of the domain logic. This language is known as Ubiquitous Language.
The ubiquitous language is important as it helps to clarify terminology that is going to be used by both users and developers. Language used in software should not be ambiguous.
In order to define the Ubiquitous Language, experts on the core domain of the application need to be consulted. This ensures that the terminology used by the software application make sense to both user experts and software engineers.
The Ubiquitous language should not be fixed. It needs to evolve and improve over time in order to accommodate for system updates and new software requirements.
Object Classification in DDD
In object-oriented programming, application data is being organised into objects. Software that follows Domain Driven Design concepts need to classify the type of objects used in the system.
Inside the context of Domain Driven Design, objects can be classified into:
- Entities. They represent unique identities which run through time. Their properties might be the same as other entities but they reference is still unique. Examples: Employee, Department, Car, Company, Insurance, etc.
- Value objects. They are usually tinny objects that are defined by the value of their properties. If two objects have the same property values, they are equal. Examples: Date, password, amounts, etc.
- Service objects. Objects that hold functionality used by other objects to perform a certain task. A running application usually has a single instance of a service object.
Aggregates in Domain Driven Design
Aggregates is a DDD pattern that groups domain objects as individual units. This pattern allows for setting up a cluster of entities and value objects which are conceptually bound together. An example of Aggregates is a customer order and its purchased products.
Aggregates define a set of boundaries that structure the internal object relations and their core domain concepts. Boundaries rules also prevent outside access to the internal object collections and properties of an aggregate. If an object wants to access an entity of an aggregate, then it needs to send the request to the aggregate root object.
By using the Aggregates pattern in Domain Driven Design the integrity of aggregate root’s internal objects is been maintained. It prevents unwanted data modification of entities and value objects.
It is important not to mix aggregate objects with standard collection data as: arrays, sets, maps… Aggregates are objects within the scope of Domain Driven Design.
Strategic Design: Bounded Context and Context Maps
Strategic Design is at the core of DDD and refers to the ability to define a software system that is aligned with the concepts and needs of its domain business. Strategic Design set the base for building up Bounded Context, Ubiquitous Language and Context Maps. In Domain Driven Design, strategic design is also known as strategic modelling.
In large software systems it is difficult to define a unique model that is going to represent the full picture of the core domain. That is why Bounded Contexts are used to divide a large system into individual bounded contexts which can hold their own unique models and unrelated concepts. Bounded Contexts can also define a unique Ubiquitous Language that is scoped within their own context.
Context Maps are used to define the relationships between Bounded Contexts in Domain Driven Design systems. Stablishing boundaries in Bounded Contexts ensure each context is unique and Context Maps help us understand how they relate to each other.
These tools allow domain experts and software engineers to stablish a common ground for building domain models using a terminology that is understandable to all team preventing ambiguity in the language that is been used.