This article covers the basic building blocks of a DDD (Domain Driven Design) approach to create your applications and systems. basic building blocks of a DDD (Domain Driven Design) 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. aligning business with technology 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. Discovering and understanding your business domain is the first step. 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.The discussion should give you a story about the business, whose outcome will be the first drafts of theubiquitous language and picture of organizational units, which then will turn into model(s) grouped by Bounded Contexts. ubiquitous language model(s) Bounded Contexts And very often, after such discussions business stakeholders start to understand their business even better than before. 🙂 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. Ubiquitous language 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. Bounded Context 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. Model current state of a Bounded Context Be selective with details, otherwise you will not see the forest for the trees! Be selective with details, otherwise you will not see the forest for the trees! 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 Strategical design This is a macro-level view of your project. Describes what to create. This is a macro-level view of your project. Describes what to create. macro-level what 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:core— what diffirintiates you in the market and where you need to put the most and the best of your resources available;supporting subdomains— the ones which supporting the core;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. 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. Ubiquitous Language 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. Ubiquitous Language Model Pay attention which parts of your business are:core— what diffirintiates you in the market and where you need to put the most and the best of your resources available;supporting subdomains— the ones which supporting the core;generic subdomains — the ones which you can completely outsource. core supporting subdomains generic subdomains 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. Model Bounded Contexts Bounded Context Model Context Map Context Map Bounded Contexts & Context Map Let’s dive deeper into those 2 concepts. 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 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. Bounded Context 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. Model Context Map Bounded Context tactical Tactical Design This is a micro-level view of your project. Describes how to create. This is a micro-level view of your project. Describes how to create. micro-level how 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. strategy strategic-level 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. Example: Money 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. 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. unique identity preserved lifecycle Example: User — userId, name, email. Example: User 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. Entities Value Objects, clear ownership boundaries ℹ️Each operation on Aggregate goes through a root Entity. Aggregate root Entity ℹ️Aggregate takes care of a consistent state of it’s cluster — no transaction can break it’s business rules. consistent state of it’s cluster Example: ShoppingCart— refers to User, Books and allowed PaymentSystem for that user.Example (rules): Order — must have ≥1 order line; can use only certain payments depending on country. Example: ShoppingCart Example (rules): Order And that’s a great another article specifically about Aggregates. And that’s a great another article specifically about Aggregates. a great another article a great another article 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. Example: AddBookToCart 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. Stack Overflow answer Stack Overflow answer Example: PricingService — computes line totals/discounts/taxes for a cart. Example: PricingService 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. Entity Example: ShoppingCartRepository — findById, findOpenByUser, save. Example: ShoppingCartRepository Below is an example of how Ordering might be modelled in a flow chart and class diagrams. 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. DDD Clean Architecture I wrote about it in my other article with a hands-on project example my other article with a hands-on project example my other article with a hands-on project example 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. the main value DDD brings better forecast your decisions

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Domain Driven Design - The Basics

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Fail Fast Philosophy, Explained

How to Find the Stinky Parts of Your Code [Part XXIX]

How to Find the Stinky Parts of Your Code [Part XXXII]

106 Stories To Learn About Clean Code

100 Pieces of Programming Advice from the Book Clean Code by Robert Martin

110 Stories To Learn About Refactoring

Fail Fast Philosophy, Explained

How to Find the Stinky Parts of Your Code [Part XXIX]

How to Find the Stinky Parts of Your Code [Part XXXII]

106 Stories To Learn About Clean Code

100 Pieces of Programming Advice from the Book Clean Code by Robert Martin

110 Stories To Learn About Refactoring

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps