Hello there. In this video we will talk about layered architecture. So, if you're ready, let's begin. A large part of the application is not directly related to the domain, but as part of the infrastructure or serves the software itself. It's possible and okay for the domain part of an application to be quite small compared to the rest. Since a typical application contains a lot of code related to database access, filer network access, user interfaces, etc. In an Object Oriented Program, UI, database and other support code often gets written directly into the business objects. Additional business logic is embedded in the behavior of UI widgets and database scripts. This sometimes happens because it is the easiest way to make things work quickly.

However, when domain related code is mixed with the other layers, it becomes extremely difficult to see and think about. Superficial changes to the UI can actually change business logic. Changing a business rule may require a meticulous tracing of UI code, database code or other program elements. Implementing coherent model driven objects becomes impractical. Automated testing is awkward. With all the technologies and logic involved in user interface application domain infrastructure in each activity, a program must be kept very simple or it becomes impossible to understand. Therefore, partition a complex program into layers. Develop a design within each layer that is cohesive and that depends only on the layers below. Follow standard architectural patterns to provide loose coupling to the layers above. Concentrate all the code related to the domain model in one layer, and isolate it from the user interface application and infrastructure code.

The domain objects free of the responsibility of displaying themselves, storing themselves, managing application tasks and so forth, can be focused on expressing the domain model. This allows a model to evolve to be rich enough and clear enough to capture essential business knowledge and put it to work. A common architectural solution for domain driven designs contains four conceptual layers; presentation layer, application layer, domain layer and infrastructure layer. The presentation layer or user interface, is responsible for presenting information to the user and interpreting user commands. The application layer is a thin layer that coordinates the application activity. It does not contain business logic, it does not hold the state of the business objects, but it can hold the state of an application task in progress. The domain layer contains information about the domain, this is the heart of business software. The state of business objects is held here. The persistence of the business objects and possibly their state are delegated to the infrastructure layer.

The infrastructure layer acts as a supporting library for all the other layers. It provides communication between layers, implements persistence for business objects and contains supporting libraries for the user interface layer. It's important to divide an application into separate layers and establish rules of interaction between the layers. If the code is not clearly separated into layers, it will soon become so entangled that it becomes very difficult to manage changes. One simple change in one section of the code may have unexpected and undesirable results in other sections. The domain layer should be focused on core domain issues. It should not be involved in infrastructure activities. The UI should be neither tightly connected to the business logic nor to the tasks that normally belong to the infrastructure layer. An application layer is necessary in many cases.

There has to be a manager of the business logic, who supervises and coordinates the overall activity of the application. For example, a typical interaction between the application, domain and infrastructure could look like this. The user wants to book a flight route, and asks an application service in the application layer to do so. The application tier fetches the relevant domain objects from the infrastructure and invokes relevant methods on them. For example, to check security margins to other already booked flights. Once the domain objects have made all checks and updated their status to decided, the application service persists the objects to the infrastructure. All right, so we talked about layered architecture in this video. Now, let's take a short break here and we'll talk about entities in the next video. I'll see you there.