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