DDD Explained in 9 MINUTES | What is Domain Driven Design?

what is the DDD and why it is important to Future proof our code let's Discover it in the next 9 Minutes a domain is the subject of a software system or application let's imagine that we are tasked to build an online Store The Domain of our software is everything that is related or necessary to operate the store we immediately realized that the domain of our online store is much more complex than we initially thought it may also require expertise from other disciplines like marketing accounting and law but I'll Grana software developer deal with such complexity the answer is we create a domain model a model is a simplify and structured abstraction that maps and documents everything of interest in the domain its main goals are to distill knowledge create a ubiquitous language and a shared understanding among all stakeholders from software data developers to Executives for the domain model to be effective it has to be binding it's like a contract everyone in the company must use its terminology if we call sanding kite everyone must use that term shopping list trolley basket they are not allowed because they would just create confusion and misunderstandings most importantly software developers need to abide by it and implement it as documented otherwise the end result is a system that does not behave as intended how do we design our model we divided design into two phases tactical design and strategic design in the Tactical phase we focus on the lower level details while in this strategic one we look at the big picture during the Tactical design phase we use the building blocks of the DDD to create a little view of our model we will send this value objects associations and other constructs let's start by defining entities an entity is a class mapping a subject or object with a well-defined identity and life cycle and it is must have unique identifiers since their equality is not based on their properties you can have two users with the same first name and last name thus you need to add unidentifier to distinguish them during the life cycle of an entity its state might change while the thread of identity is continued imagine a product whose price fluctuates while it suddenly this constant a value object represents an element of the model that has no conceptual identity to Value objects are equal when their properties are equal imagine an address defined by these properties if you have twistances of this class with the same values the assistances are considered equal value objects enrich the model with details in fact they are often used with entities to keep them lean the address would be defined as a property of the user entity once the user is deleted the address is deleted with it as well and now we talk about associations object in our domain are interconnected by some sort of relationship that's known as an association most relationship in real life are bi-directional another contains one or more products while a product can be part of multiple artists that's an example of a many-to-many relationships such relationships are difficult to implement the mundane in code for this reason we can optimize our model by embossing a traversal Direction in our scenario I would favor the direction starting from order it is the most natural one when we visualize an order we want to see the products while the reverse will be extremely rare other options to simplify associations are to leverage one to one and one to many relationships an account can be restricted to only one cards while the relationship between order and not their items is someone too many at times it might be difficult to represent a concept as an entity or a value object this is particularly true when we want to map an operation rather than someone or something in this case we use services a service is a stateless operation whose interface is defined by other elements of the modern the service stands alone in the model and there's no associations we would create a service that accepts a northern and payment method performs the actual payment and Returns the transaction details services are very common in Frameworks Unfortunately they are also abused it is not uncommon to see an image models in these models all of the logic is stored in Services while entities are simply sterile Banks of data with no Behavior this is against the core idea of DDD entities should encapsulate behavior for instance an entity is responsible to protect its state from being corrupted it should not rely on an external class to do that and now we talk about Aggregates and factories when the models start growing large we use Aggregates to group a set of closely related entities we establish a boundary and the route which we use to control all access to the objects inside this way we can simplify our model by allowing references only to aggregate routes and we can guarantee sanity of the entire Aggregates as all to build and interact with complex objects like Aggregates with genius factories factories could be methods for example we could expose a method on orders to create new line items factories can also be Standalone classes which generate Aggregates or entities for example we would have an order effectively generating sequentially numbered orders and finally we have repositories that are used to retrieve particular distances of our entities their main goal is to avoid crowd in the entity with quitting and persistent concerns which would bloat it we can create an ordered repository where we can fetch order via this account or date range and that's all for the Tactical design now we focus on strategic design as you may have noticed a common concern is that one to reduce complexity the answer is always to introduce some form of boundary that allows us to focus on a particular aspect of our model and reduce the complexity of all the possible associations with other objects the larger the project we're working on the irr the chances that creating a unified model is not visible we might need multiple teams to work concurrently to deliver the entire model in the Strategic design phase we decompose our model into distinct sub models by creating bounded contacts within the bounded contest we are able to continuously build tests and optimize the model independently from other contexties we also specialize its function and create a more precise dialect that is used by the team members and experts involved in it if you are wondering if there is any relation to microservices you are spot on strategic DDD is often used to define the competencies of a microservice I will talk more about that in another video associations obviously exist also between bounded contacts and they can become complex very quickly to address this issue we can create a contest map where we document the points of contact between the different models an effective context map defines clear names and boundaries for each context that they are shared by all teams the relationships between models and teams are even more complex than those we saw in tactical design this is because they not only affect daytime features but most importantly they affect the way different software development teams integrate with each other there are several ways to govern these relationships as a customer to another team that's known as the customer Supply relationship another approach could be to have two or more teams share a portion of their models where they collaborate that's the share kernel another common approach especially when dealing with models outside our control is to create an anti-corruption layer which allows us to give our model focused on its subject and use this layer to perform the translation to another model as you can imagine strategic DDD can become really complex and we just touch the surface a lot of the information I shared is based on the domain-driven design book by Eric Evans and I'm leaving you the link in the description if you enjoyed the video like And subscribe and see you next time

Channel: Marco Lenzo

Views: 37,596

Keywords: ddd, domain driven design, domain-driven design, software engineering, software developer, software engineer, ddd explained, domain driven design explained, domain-driven design explained, ddd microservices, domain-driven-design explained, ddd entity, ddd aggregate, tactical ddd, strategic ddd, microservices, monolith, ddd book, ddd book eric evans, domain-driven-design book

Id: kbGYy49fCz4

Length: 9min 44sec (584 seconds)

Published: Tue Feb 07 2023