This content originally appeared on HackerNoon and was authored by Pavlo Lozovikov
This article covers the basic building blocks of a DDD (Domain Driven Design) approach to create your applications and systems.
Generally speaking, DDD gives us a framework for a way of aligning business with technology throughout the whole project lifecycle. It closes the gap between all project participants and knowledge domains in a way that allows to streamline the efforts more effectively.
Explore your domain
==Discovering and understanding your business domain is the first step.== You’ll figure out which parts of your business your application will cover and what exactly differentiates your business from your competitors, so you can clearly understand where to put the most of the best resources.
Create a discussion group of people who carry the business knowledge — such as stakeholders or domain experts — and technical people who will later translate it into technical languages. \n The discussion should give you a story about the business, whose outcome will be the first drafts of the ubiquitous language and picture of organizational units, which then will turn into model(s) grouped by Bounded Contexts.
And very often, after such discussions business stakeholders start to understand their business even better than before. 🙂
Ubiquitous language — the vocabulary to be used while speaking about the project and to name your packages/objects/relations or even microservices. Positive outcome — everyone will be on the same page of a project’s understanding and amount of confusions during imlementations will be avoided by design.
Bounded Context — cohesively grouped part of the business which shaped and modelled with it’s own concepts, terminology, rules and even dialects of a Ubiquitous Language.
Model — a visual representation of a current state of a Bounded Context, usually in a whiteboard format. Then you can express with UML or any other diagram style it’s parts for more clarity.
:::warning Be selective with details, otherwise you will not see the forest for the trees!
:::
Model & Design
When your first discussion is over and you already have plenty of textual notes and some visual sketches (without any technological aspects in mind!) — it’s perfect, because now you can start a strategical design.
Strategical design
:::info This is a macro-level view of your project. Describes what to create.
:::
- Distill the Ubiquitous Language from your notes and create a glossary for your project — this is the core meanings which then will be represented in all of the next steps and must be always kept in synchronization throughout the whole further project’s lifecycle.
- Align your draw-sketches with the Ubiquitous Language so the visual representation telling the story about the business, its parts and relations between them in the same language, but just from the visual perspective — it will set the stage for further implementation steps. It will become the first version of your Model.
- Pay attention which parts of your business are: \n core — what diffirintiates you in the market and where you need to put the most and the best of your resources available; \n supporting subdomains — the ones which supporting the core; \n generic subdomains — the ones which you can completely outsource.
- Cohesively group parts of your Model visualization to form Bounded Contexts. Each Bounded Context will be represented through it’s own Model which relations will be shaped in a Context Map. Context Map often acts as a “glue” between project management and developers teams. As a result, things will become more organized and this sets the stage for your next tactical steps.
Bounded Contexts & Context Map
Let’s dive deeper into those 2 concepts.
After your first version of a business view is created (might be just a single model), you need to cohesively group them into a selectively organized (distilled) knowledge which aim to tell a certain story about this part of the business. Each of those groups called Bounded Context.
Bounded Context hiding not only implementation but also domain complexity from the other organizational boundaries, but sharing part of the contexts which is common for multiple organizational contexts. This “public aggregates” will later be mapped to connections between Services.
As a result, your more organized Model will become a Context Map, which holds and explains relations between each Bounded Context. And quality of this project phase will inevitably impact on quality of the tactical steps which should be taken next.
Tactical Design
:::info This is a micro-level view of your project. Describes how to create.
:::
After everyone is aligned on the strategy, we can zoom in to plan the implementation by bringing our strategic-level knowledge to the more tech people to express it through technology.
In Domain-Driven Design (DDD), there are several distinct concepts that holding specific meaning for the implementation part and helping all participants to communicate about what a piece of code (class/object/package/etc.) represents — the same goal as design patterns, but more DDD-driven.
Value Object
The smallest consistent unit of knowledge of your business which is immutable, does not require any unique identity and lifecycle of an object.
Example: Money — amount, currency.
:::warning Do not misinterpret that Value Object should be always small. It can be also a huge entity, but still immutable, without any unique identity and managed lifecycle.
:::
Entity
You can think of it as an “extended Value Object” with added “features” on top, like unique identity and preserved lifecycle of an instance.
Example: User — userId, name, email.
Aggregate
You can think of it as a business-meaningful instance which has it’s own identity, state and lifecycle, composed of other Entities and/or Value Objects, forming a cohesive cluster with clear ownership and boundaries. The cohesiveness is ensured by Aggregate’s rules invoked by it’s each invoked operation.
ℹ️Each operation on Aggregate goes through a root Entity.
ℹ️Aggregate takes care of a consistent state of it’s cluster — no transaction can break it’s business rules.
Example: ShoppingCart — refers to User, Books and allowed PaymentSystem for that user. \n Example (rules): Order — must have ≥1 order line; can use only certain payments depending on country.
And that’s a great another article specifically about Aggregates.
Use Case
Describes how the application meets a particular business goal.
Operates on abovementioned Domain Concepts and never including details — everything is hidden behind abstractions.
Example: AddBookToCart — Getting book + user inputs, calls aggregate transaction and calling analytics service to process the user behavior data.
Service
Stateless domain logic that doesn’t fit any existing Entity, Value Object or Aggregate. Often abstracts away a calls to some third-party service.
Services can also come in different flavours, for details refer to this Stack Overflow answer.
Example: PricingService — computes line totals/discounts/taxes for a cart.
Repository
Encapsulates any transition logic to and from persistence data storage. Abstracts away persistence complexity with business-relevant APIs.
Sometimes can be used to reconstitute an Entity if it’s data is palced in multiple databases.
Example: ShoppingCartRepository — findById, findOpenByUser, save.
Below is an example of how Ordering might be modelled in a flow chart and class diagrams.
Conclusion
This article presented only the core of DDD. In real projects, it will be complemented by supportive approaches such as Clean Architecture (I wrote about it in my other article with a hands-on project example) or a bunch of other patterns.
From my perspective, the main value DDD brings is the ability to view a project from multiple angles and to step into the shoes of different roles — both technical and non-technical. As a result, it gives you possibility to better forecast your decisions.
This content originally appeared on HackerNoon and was authored by Pavlo Lozovikov
Pavlo Lozovikov | Sciencx (2025-08-22T07:11:37+00:00) Domain Driven Design – The Basics. Retrieved from https://www.scien.cx/2025/08/22/domain-driven-design-the-basics/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.