Domain Driven Design: What You Need To Know

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

Channel: Alex Hyett

Views: 42,973

Keywords: domain driven design, ddd, software architecture, domain driven design eric evans, what is domain driven design, software architecture patterns, software architecture and design, software architecture fundamentals, domain-driven design, review what is domain driven design, strategic design, tactical design, bounded context, domain driven design bounded context, ubiquitous language, context mapping ddd, value object, software engineering, software engineer, context mapping

Id: 4rhzdZIDX_k

Length: 8min 42sec (522 seconds)

Published: Fri Apr 28 2023