Domain Driven Design: What You Need To Know

[00:00] hey friends welcome back to the channel

[00:01] now when we're trying to build complex

[00:03] software it's really important that

[00:05] everyone is on the same page even though

[00:06] I know most of us prefer to work at home

[00:08] alone with an endless supply of coffee

[00:10] good software just isn't built that way

[00:12] the software that you build should

[00:14] represent the business and it should be

[00:15] clear from the code how the business

[00:17] functions software development is

[00:19] difficult enough without the business

[00:20] and Engineering using different names

[00:21] for the same thing this is where

[00:23] domain-driven design or DDD for short

[00:25] comes in which was made Popular by Eric

[00:27] Evans in his 2003 book domain-driven

[00:30] design in this video I'm going to be

[00:31] covering the key Concepts that you need

[00:33] to know to be able to use DDD in your

[00:35] next project the first step is what we

[00:36] call Strategic design even though it's

[00:38] possible to use DDD in an existing

[00:40] application it's much easier when the

[00:42] application is built with it in mind so

[00:44] we need to work out what the different

[00:45] subdomains are in the business a domain

[00:47] in this case refers to the subject area

[00:49] in which we're building the application

[00:50] and subdomains are a part of that

[00:52] application it's really important when

[00:54] you're working out the subdomains that

[00:56] everyone is using the same language you

[00:58] want the words that you use to describe

[00:59] objects in your application to be the

[01:01] same ones that are used by the business

[01:02] this has the grand name of ubiquitous

[01:04] language which is really just a fancy

[01:06] way of saying everyone needs to use the

[01:08] same words so let's use Netflix as an

[01:10] example if we were to build Netflix from

[01:12] scratch using DDD what sub domains would

[01:15] we have so obviously we have video

[01:16] streaming which is one of the main parts

[01:18] of the business and therefore this is

[01:19] what we call a core domain and then we

[01:21] might have recommendations as another

[01:23] subdomain and maybe billing which

[01:25] handles all of the subscriptions there

[01:27] are of course going to be quite a few

[01:28] other domains we haven't covered here

[01:29] but this will give you an idea of how

[01:31] DDD works now working out what the

[01:33] subdomains are should always be done as

[01:35] a group exercise with the business if

[01:37] the engineering team tries to work out

[01:38] what all of the subdomains are

[01:40] themselves then it might not be

[01:41] representative of the business which

[01:43] kind of defeats the whole point of

[01:44] domain-driven design the aim here is to

[01:47] end up with a system that represents the

[01:48] real world domain that you're trying to

[01:50] solve working out all the domains is

[01:52] going to be an iterative process you

[01:54] might find that one of the domains is

[01:55] huge and needs to be broken down further

[01:57] once you've worked out what all the

[01:58] domains are the next step is to work out

[02:00] the key parts of each of those domains

[02:02] if we take a closer look at the billing

[02:04] domain we'll probably find inside we'll

[02:06] have things like subscribers accounts

[02:08] payment details and subscription plans

[02:09] what you'll notice when you go through

[02:11] this exercise is there'll be parts that

[02:13] will be coming across multiple

[02:14] subdomains for example the subscribers

[02:16] will likely come up across the whole

[02:17] system the billing domain might call

[02:19] them subscribers or maybe even customers

[02:21] whereas the streaming domain is more

[02:23] likely to call them viewers DDD copes

[02:25] with this by what is called a bounded

[02:26] context each subdomain will have its own

[02:28] bounded context allowing the language to

[02:30] be used to be different for each of the

[02:32] subdomains you don't need to get the

[02:33] whole business to agree on what to call

[02:35] subscribers you just need to agree on

[02:37] what to call them in each of the

[02:38] subdomains if you've done a good job you

[02:40] should find some clear separation

[02:41] between the different subdomains and the

[02:43] language used each subdomain should have

[02:45] at least a few things that are unique to

[02:47] just that domain for example the billing

[02:49] domain will likely have payment details

[02:51] which you wouldn't expect to see in any

[02:52] of the other domains the aim here is to

[02:54] build up a model of all the different

[02:56] elements that make up each of the

[02:57] domains these elements are what we call

[02:59] entities which will cover in a bit more

[03:00] detail in a minute if you're liking this

[03:02] video so far you might like my Weekly

[03:04] Newsletter the Curious engineer where I

[03:06] cover everything you need to know to

[03:08] level up as a software developer I've

[03:09] added a link in the description so you

[03:11] can check it out so now that we know

[03:13] what all the different subdomains are

[03:14] our next step is to work out what the

[03:16] relationships are between them we do

[03:18] this by creating what we call a context

[03:20] map which outlines which domains to

[03:22] communicate with each other how they

[03:23] communicate and the direction that

[03:25] they're communicating in the

[03:26] interactions between the different

[03:27] subdomains will usually happen between

[03:29] the different entities now if we go back

[03:31] to the Netflix example the video

[03:33] streaming domain is going to need to

[03:34] know what quality of video to show to

[03:36] the viewers this of course all depends

[03:37] on the subscription that they're paying

[03:39] for if they're a basic user then they'll

[03:41] get HD they're a standard user they'll

[03:43] get full HD and if they're a premium

[03:45] user they'll get Ultra HD the

[03:47] subscription plan however is outside the

[03:49] bounded context of the streaming domain

[03:51] it doesn't care what users are paying it

[03:53] only cares about streaming videos the

[03:55] streaming domain therefore needs to

[03:56] check with a billing domain to work out

[03:58] what quality video to show to the user

[04:00] of course the billing domain doesn't

[04:01] care about video quality only cares

[04:03] about the subscription plans so we need

[04:05] to do a mapping between the viewer and

[04:07] the streaming domain and the subscriber

[04:09] in the billing domain now to make sure

[04:10] that we don't pollute either of the

[04:12] domains with information that doesn't

[04:13] need to be there we create what we call

[04:15] an anti-corruption layer which does the

[04:17] translation between the domains for us

[04:19] once we've outlined all the domains and

[04:21] how they interact we go on to the next

[04:23] step which is tactical design in this

[04:25] stage we look at trying to refine our

[04:26] domain models a little bit further to do

[04:28] this we look at each of our domains and

[04:30] try and work out what the objects are

[04:31] inside them now domain objects come in

[04:33] two forms so first we have entities the

[04:36] entities of the domain link to their

[04:38] real world counterparts so in our

[04:40] Netflix example we might have

[04:41] subscribers as one of our entities each

[04:43] entity has an ID and it's this ID that

[04:45] makes them unique if all the other

[04:47] properties are exactly the same if the

[04:49] IDS are different they're considered

[04:51] different entities entities are mutable

[04:53] you can change their properties over

[04:55] time for example a subscriber might

[04:57] change their email address but if the ID

[04:59] stays the same is still considered the

[05:01] same subscriber the other domain object

[05:02] to consider are what we call Value

[05:04] objects a value object as the name

[05:06] suggests generally corresponds to a

[05:07] value in your domain entities can have

[05:09] several different value objects in them

[05:11] for example a subscriber is likely to

[05:13] have an email address as well as a date

[05:14] of birth value objects are not unique

[05:16] and two objects with the same value are

[05:18] considered to be equal if you're

[05:20] creating value objects in c-sharp or

[05:22] Java then you're going to need to

[05:23] override the equals and hash code

[05:25] methods this ensures that when you

[05:27] compare them in your code the computer

[05:28] knows that they're equal unlike entities

[05:30] value objects are immutable you can't

[05:32] update them and if you need a different

[05:34] value then you just need to create a new

[05:36] one we generally do this by only

[05:37] allowing values to be set in the

[05:39] Constructor when the object's created

[05:40] and then we don't set up any Setter

[05:42] methods to allow you to update them the

[05:44] key thing to understand here is they are

[05:45] an object you could just as easily

[05:47] create a string to store the email

[05:49] address but by creating a value object

[05:51] you're explicitly stating that this is

[05:52] an important part of your domain the

[05:54] fact that it's an object means you can

[05:56] add additional validation and business

[05:57] logic into the Constructor this can be

[05:59] really be useful for example if you have

[06:01] an email address object you don't need

[06:02] to check everywhere in your code you

[06:04] have a valid email address as that would

[06:06] have been done when it was created even

[06:08] if you don't end up using domain driven

[06:09] design value objects can be really

[06:11] useful for writing cleaner code in your

[06:13] applications when modeling your object

[06:15] it can be difficult to decide whether

[06:16] something should be an entity or value

[06:18] object generally it depends on how

[06:21] important that object is in your domain

[06:22] model for example in many domains an

[06:25] address is just information it may be

[06:27] included in the billing details but it

[06:28] doesn't actually have any importance in

[06:30] the system beyond that now imagine

[06:32] you're creating a real estate

[06:33] application now the address isn't just

[06:35] information it's an important part of

[06:37] understanding the property in this case

[06:39] the address would more likely be an

[06:40] entity than it would be a value object

[06:42] generally you want to have more value

[06:43] objects than entities in your domain as

[06:45] value objects are small and immutable

[06:47] which makes them easier to work with now

[06:49] that we know about entities and value

[06:51] objects the next important thing you

[06:52] need to know in DDD is called an

[06:54] Aggregate and aggregate as the name

[06:55] suggests is a group of several entities

[06:57] and value objects an example could be a

[06:59] customers order it's made up of the

[07:01] customer the products they ordered the

[07:03] order price as well as information such

[07:05] as the shipping address and aggregate

[07:07] also makes up a transactional boundary

[07:09] so whenever changes are made to the

[07:11] aggregate they should be either

[07:12] committed or rolled back to the database

[07:14] this way we can ensure that aggregate is

[07:17] always in a consistent State like

[07:18] entities Aggregates also have an ID

[07:21] which means they can be referenced from

[07:22] different parts of the application the

[07:24] aggregate is also responsible for

[07:25] maintaining business and variants these

[07:28] are just business rules that always

[07:29] remain true no matter what you do to

[07:31] your system for example you might have a

[07:33] rule that says the order total needs to

[07:34] be a sum of all the products ordered you

[07:36] might have another rule that stops

[07:38] people from ordering more than what is

[07:39] in stock obviously all of this comes at

[07:41] a cost the more rules that you add into

[07:43] an aggregate the longer it's going to

[07:44] take to update it which could affect

[07:46] user experience so generally there is a

[07:48] bit of a trade-off between performance

[07:50] and consistency that you need to keep in

[07:52] mind in some cases it might make more

[07:54] sense to set up what we call a

[07:55] corrective policy that runs on a regular

[07:57] basis to either flag or correct anything

[08:00] that might be wrong finally we have

[08:02] repositories and services which if

[08:04] you've done any back-end development

[08:06] you're going to be familiar with the

[08:07] repositories in this case are the

[08:09] persistence layer for our Aggregates so

[08:10] that they can be stored in the database

[08:12] then we have the services which contain

[08:14] additional business logic which either

[08:16] doesn't fit in a single aggregate or

[08:18] spans multiple Aggregates once you have

[08:19] everything mapped out you're ready to

[08:21] build your application one of the best

[08:23] ways to build out a domain-driven

[08:24] application is using hexagonal

[08:26] architecture and if you haven't already

[08:28] it's worth watching this video next

[08:29] thank you for watching please like And

[08:31] subscribe if you haven't already and

[08:33] I'll see you in the next video