Hello there, in this video, we will talk about domain-driven design. So, let's begin. Domain driven design or DDD, is a development philosophy defined by Eric Evans in his seminal work, Domain Driven Design: Tackling Complexity in the Heart of Software. DDD Is an approach to software development that enables teams to effectively manage the construction and maintenance of software for complex problem domains. In other words, domain-driven design advocates a philosophy on how software should be modeled in order to adapt it to the digital world by creating real world business models with a common language, ubiquitous language, that everyone can understand. To understand how DDD can help with the design of software for a non-trivial domain, you must first understand the difficulties of creating and maintaining software. By far, the most popular software architectural design pattern for business applications is the Big Ball of Mud (BBOM) pattern.

The definition of BBOM, as defined by Brian Foote and Joseph Yoder in the paper, Big Ball of Mud, is a haphazardly structured, sprawling, sloppy duct tape and bailing wire spaghetti code jungle. Foote and Yoder use the term BBOM to describe an application that appears to have no distinguishable architecture. Think of a big bowl of spaghetti versus a dish of layered lasagna. The issue with allowing software to dissolve into a BBOM, becomes apparent when routine changes in workflow and small feature enhancements become a challenge to implement due to the difficulties in reading and understanding the existing code base. Eric Evans describes such systems in his book as containing, code that does something useful but without explaining how. One of the main reasons software becomes complex and difficult to manage is the mixing of domains. So, now that we've talked about domain driven design, let's look at some of the terms used. Domain model. Domain-driven design recommends using the domain model, which is a diagram to reflect the impact plan of the application.

A domain model should contain the total idea of the domain of the software to be built and it should be in such a way, that everyone can understand what it means about the relevant operation. The domain model has all the property names in it and is usually supported by images as opposed to UML diagrams. According to Eric Evans, the domain model is not a specific diagram, it is the idea that the diagram aims to convey. And it's not just the knowledge in the field experts head, it's a meticulously organized abstraction of that knowledge. Domain expert. If a software developer is told to develop an application for air traffic routing, it will not be possible for the developer to do so without any knowledge of the subject. In order for the software developer to perform this work, information such as aircraft, aircraft traffic, where to direct traffic, how to direct traffic and the legislation of the business should be clarified. It's not possible to develop software without a person who has mastered these issues.

This person is now a domain expert for us. Ubiquitous language. This term provides the common communication between the software team and the domain expert and expresses that it should be provided. Although domain experts have deep and sufficient knowledge of their field, they may not know anything about software development. The same can be true for a software developer and there may be no information about the area to be studied. In such a case, domain driven design recommends that there be a common language between the software developer and the domain experts so that both parties can understand it easily. Bounded context. The most central principle in domain driven design, is bounded context. Bounded contexts are structures that are separated from each other and whose boundaries are determined. We can also deduct bounded contexts as projects or microservices corresponding to each service in micro service architectures. They are independent autonomous units that can be developed and operated without other services.

In an e-commerce app, for example, each area, such as the place where products are searched and listed, the shopping cart and the purchasing functions, is actually a separately bounded context. Each of these functions can be developed alone without the other. Context mapping. The ability to explain the intersections of bound context with each other based on the communication architecture between them, is called context mapping. In other words, context mapping is the tool that allows you to determine the relationship between bounded context and the teams responsible for them. For example, having the customer number in the order's table, but not having anything about the order in the customer table, that is setting these limits, is a context mapping. Clean and readable code. While building the code, it should be built to reflect the purpose of the domain.

What should be considered here is not how practical or standard the names given to the structures are, but how well they describe the work they do, even if they are alone. Also when we write our code, we need to do so in a way that not only we, but anyone else who reads it can understand it. This is also an important issue and domain-driven designs recommendation. Alright, so I think domain-driven design has taken shape a little more in your mind. Let's take a short break here and I'll see you in the next video.