---
title: 'Domain Driven Design: What You Need To Know'
source: 'https://youtube.com/watch?v=4rhzdZIDX_k'
video_id: '4rhzdZIDX_k'
date: 2026-06-14
duration_sec: 522
---

# Domain Driven Design: What You Need To Know

> Source: [Domain Driven Design: What You Need To Know](https://youtube.com/watch?v=4rhzdZIDX_k)

## Summary

This video explains the key concepts of Domain-Driven Design (DDD), a methodology for building software that closely models the business domain. It covers strategic design, including subdomains and ubiquitous language, and tactical design, including entities, value objects, aggregates, and repositories.

### Key Points

- **What is DDD?** [00:23] — Domain-Driven Design (DDD) is a methodology popularized by Eric Evans in his 2003 book. It aims to align software design with business domain language.
- **Strategic Design: Subdomains** [00:36] — Strategic design involves identifying subdomains within the business. A domain is the subject area of the application, and subdomains are its parts.
- **Ubiquitous Language** [00:58] — Ubiquitous language means using the same terms for objects in code as the business uses. This ensures everyone is on the same page.
- **Netflix Example: Core Domain** [01:10] — Using Netflix as an example, video streaming is a core domain. Other subdomains include recommendations and billing.
- **Collaborative Domain Modeling** [01:33] — Identifying subdomains should be a group exercise with business stakeholders to ensure accuracy.
- **Bounded Context** [02:00] — Each subdomain has its own bounded context, allowing different terminology for the same concept across domains (e.g., 'subscriber' vs 'viewer').
- **Context Map** [03:13] — A context map outlines relationships between subdomains, including how they communicate and in which direction.
- **Anti-Corruption Layer** [04:15] — An anti-corruption layer translates between domains to prevent pollution of each domain's model.
- **Tactical Design: Entities** [04:25] — Entities are domain objects with a unique ID. They are mutable and represent real-world objects (e.g., a subscriber).
- **Value Objects** [05:02] — Value objects are immutable and defined by their attributes. Two value objects with the same values are considered equal. They encapsulate validation and business logic.
- **Entity vs Value Object Decision** [06:15] — Whether something is an entity or value object depends on its importance in the domain. For example, an address might be a value object in billing but an entity in a real estate app.
- **Aggregates** [06:49] — An aggregate is a group of entities and value objects that form a transactional boundary. It has an ID and enforces business invariants (rules that must always hold).
- **Repositories and Services** [08:02] — Repositories handle persistence for aggregates. Services contain business logic that doesn't fit in a single aggregate or spans multiple aggregates.

### Conclusion

DDD helps create software that accurately reflects the business domain, improving communication and maintainability. The video recommends using hexagonal architecture to implement DDD effectively.

## Transcript

hey friends welcome back to the channel
now when we're trying to build complex
software it's really important that
everyone is on the same page even though
I know most of us prefer to work at home
alone with an endless supply of coffee
good software just isn't built that way
the software that you build should
represent the business and it should be
clear from the code how the business
functions software development is
difficult enough without the business
and Engineering using different names
for the same thing this is where
domain-driven design or DDD for short
comes in which was made Popular by Eric
Evans in his 2003 book domain-driven
design in this video I'm going to be
covering the key Concepts that you need
to know to be able to use DDD in your
next project the first step is what we
call Strategic design even though it's
possible to use DDD in an existing
application it's much easier when the
application is built with it in mind so
we need to work out what the different
subdomains are in the business a domain
in this case refers to the subject area
in which we're building the application
and subdomains are a part of that
application it's really important when
you're working out the subdomains that
everyone is using the same language you
want the words that you use to describe
objects in your application to be the
same ones that are used by the business
this has the grand name of ubiquitous
language which is really just a fancy
way of saying everyone needs to use the
same words so let's use Netflix as an
example if we were to build Netflix from
scratch using DDD what sub domains would
we have so obviously we have video
streaming which is one of the main parts
of the business and therefore this is
what we call a core domain and then we
might have recommendations as another
subdomain and maybe billing which
handles all of the subscriptions there
are of course going to be quite a few
other domains we haven't covered here
but this will give you an idea of how
DDD works now working out what the
subdomains are should always be done as
a group exercise with the business if
the engineering team tries to work out
what all of the subdomains are
themselves then it might not be
representative of the business which
kind of defeats the whole point of
domain-driven design the aim here is to
end up with a system that represents the
real world domain that you're trying to
solve working out all the domains is
going to be an iterative process you
might find that one of the domains is
huge and needs to be broken down further
once you've worked out what all the
domains are the next step is to work out
the key parts of each of those domains
if we take a closer look at the billing
domain we'll probably find inside we'll
have things like subscribers accounts
payment details and subscription plans
what you'll notice when you go through
this exercise is there'll be parts that
will be coming across multiple
subdomains for example the subscribers
will likely come up across the whole
system the billing domain might call
them subscribers or maybe even customers
whereas the streaming domain is more
likely to call them viewers DDD copes
with this by what is called a bounded
context each subdomain will have its own
bounded context allowing the language to
be used to be different for each of the
subdomains you don't need to get the
whole business to agree on what to call
subscribers you just need to agree on
what to call them in each of the
subdomains if you've done a good job you
should find some clear separation
between the different subdomains and the
language used each subdomain should have
at least a few things that are unique to
just that domain for example the billing
domain will likely have payment details
which you wouldn't expect to see in any
of the other domains the aim here is to
build up a model of all the different
elements that make up each of the
domains these elements are what we call
entities which will cover in a bit more
detail in a minute if you're liking this
video so far you might like my Weekly
Newsletter the Curious engineer where I
cover everything you need to know to
level up as a software developer I've
added a link in the description so you
can check it out so now that we know
what all the different subdomains are
our next step is to work out what the
relationships are between them we do
this by creating what we call a context
map which outlines which domains to
communicate with each other how they
communicate and the direction that
they're communicating in the
interactions between the different
subdomains will usually happen between
the different entities now if we go back
to the Netflix example the video
streaming domain is going to need to
know what quality of video to show to
the viewers this of course all depends
on the subscription that they're paying
for if they're a basic user then they'll
get HD they're a standard user they'll
get full HD and if they're a premium
user they'll get Ultra HD the
subscription plan however is outside the
bounded context of the streaming domain
it doesn't care what users are paying it
only cares about streaming videos the
streaming domain therefore needs to
check with a billing domain to work out
what quality video to show to the user
of course the billing domain doesn't
care about video quality only cares
about the subscription plans so we need
to do a mapping between the viewer and
the streaming domain and the subscriber
in the billing domain now to make sure
that we don't pollute either of the
domains with information that doesn't
need to be there we create what we call
an anti-corruption layer which does the
translation between the domains for us
once we've outlined all the domains and
how they interact we go on to the next
step which is tactical design in this
stage we look at trying to refine our
domain models a little bit further to do
this we look at each of our domains and
try and work out what the objects are
inside them now domain objects come in
two forms so first we have entities the
entities of the domain link to their
real world counterparts so in our
Netflix example we might have
subscribers as one of our entities each
entity has an ID and it's this ID that
makes them unique if all the other
properties are exactly the same if the
IDS are different they're considered
different entities entities are mutable
you can change their properties over
time for example a subscriber might
change their email address but if the ID
stays the same is still considered the
same subscriber the other domain object
to consider are what we call Value
objects a value object as the name
suggests generally corresponds to a
value in your domain entities can have
several different value objects in them
for example a subscriber is likely to
have an email address as well as a date
of birth value objects are not unique
and two objects with the same value are
considered to be equal if you're
creating value objects in c-sharp or
Java then you're going to need to
override the equals and hash code
methods this ensures that when you
compare them in your code the computer
knows that they're equal unlike entities
value objects are immutable you can't
update them and if you need a different
value then you just need to create a new
one we generally do this by only
allowing values to be set in the
Constructor when the object's created
and then we don't set up any Setter
methods to allow you to update them the
key thing to understand here is they are
an object you could just as easily
create a string to store the email
address but by creating a value object
you're explicitly stating that this is
an important part of your domain the
fact that it's an object means you can
add additional validation and business
logic into the Constructor this can be
really be useful for example if you have
an email address object you don't need
to check everywhere in your code you
have a valid email address as that would
have been done when it was created even
if you don't end up using domain driven
design value objects can be really
useful for writing cleaner code in your
applications when modeling your object
it can be difficult to decide whether
something should be an entity or value
object generally it depends on how
important that object is in your domain
model for example in many domains an
address is just information it may be
included in the billing details but it
doesn't actually have any importance in
the system beyond that now imagine
you're creating a real estate
application now the address isn't just
information it's an important part of
understanding the property in this case
the address would more likely be an
entity than it would be a value object
generally you want to have more value
objects than entities in your domain as
value objects are small and immutable
which makes them easier to work with now
that we know about entities and value
objects the next important thing you
need to know in DDD is called an
Aggregate and aggregate as the name
suggests is a group of several entities
and value objects an example could be a
customers order it's made up of the
customer the products they ordered the
order price as well as information such
as the shipping address and aggregate
also makes up a transactional boundary
so whenever changes are made to the
aggregate they should be either
committed or rolled back to the database
this way we can ensure that aggregate is
always in a consistent State like
entities Aggregates also have an ID
which means they can be referenced from
different parts of the application the
aggregate is also responsible for
maintaining business and variants these
are just business rules that always
remain true no matter what you do to
your system for example you might have a
rule that says the order total needs to
be a sum of all the products ordered you
might have another rule that stops
people from ordering more than what is
in stock obviously all of this comes at
a cost the more rules that you add into
an aggregate the longer it's going to
take to update it which could affect
user experience so generally there is a
bit of a trade-off between performance
and consistency that you need to keep in
mind in some cases it might make more
sense to set up what we call a
corrective policy that runs on a regular
basis to either flag or correct anything
that might be wrong finally we have
repositories and services which if
you've done any back-end development
you're going to be familiar with the
repositories in this case are the
persistence layer for our Aggregates so
that they can be stored in the database
then we have the services which contain
additional business logic which either
doesn't fit in a single aggregate or
spans multiple Aggregates once you have
everything mapped out you're ready to
build your application one of the best
ways to build out a domain-driven
application is using hexagonal
architecture and if you haven't already
it's worth watching this video next
thank you for watching please like And
subscribe if you haven't already and
I'll see you in the next video