Patterns of Enterprise Application Architecture-Day 6

Today we start the chapter 4 about Architecture.
Fllow me 😄

Chapter 4 : Architecture

A. Layers Architecture Pattern

The Layers Architecture [Buschmann et al.] pattern is considered by many to be the granddaddy of all. It supports N-tier systems and is, thus, commonly used in Web, enterprise, and desktop applications. Here we rigorously separate the various concerns of our application or system into well-defined layers.

• 1️⃣ The Traditional

An essential rule of this architecture is that each layer may couple only to itself and below. There are distinctions within the style. A Strict Layers Architecture is one that allows coupling only to the layer directly below. A Relaxed Layers Architecture, however, allows any higher-level layer to couple to any layer below it. Since both the User Interface and the Application Services often need to employ infrastructure, many, if not most, systems are based on Relaxed Layers.

• User Interface

The User Interface is to contain only code that addresses user view and request concerns. It must not contain domain/business logic. Some may conclude that since validation is required by the User Interface, it must contain business logic. The kinds of validation found in the User Interface are not the kinds that belong in the domain model (only). As discussed in Entities (5), we still want to limit coarse-grained validations that express deep business knowledge only to the model. If the User Interface components use objects from the domain model, it is generally limited to rendering its data on the glass. If using this approach, a Presentation Model (14) can be used to prevent the view itself from knowing about domain objects. Since a user may be either a human or other systems, sometimes this layer will provide the means to remotely invoke the services of an API in the form of an Open Host Service (13).

• Application Layer

Components in the User Interface are direct clients of the Application Layer. Application Services (14) reside in the Application Layer. These are different from Domain Services (7) and are thus devoid of domain logic. They may control persistence transactions and security. They may also be in charge of sending Event-based notifications to other systems and/or for composing e-mail messages to be sent to users. The Application Services in this layer are the direct clients of the domain model, though themselves possessing no business logic. They remain very lightweight, coordinating operations performed against domain objects, such as Aggregates (10). They are the primary means
of expressing use cases or user stories on the model.

• Infrastructure Layer

Using Layers may require the Domain Layer to make some limited use of Infrastructure. I’m not saying that core domain objects would do this, as we should absolutely avoid that altogether. However, adhering to the definition of Layers may require implementations of some interfaces in the Domain Layer
that depend on technologies provided by Infrastructure.
For example, Repository interfaces require implementations that use components, such as persistence mechanisms, housed in Infrastructure.

❌ Problems with the Traditional Layers Architecture

In a traditional Layers Architecture the Infrastructure is at the bottom. Things like persistence and messaging mechanisms reside there. Messages may include those sent by enterprise messaging middleware systems or more basic e-mails (SMTP) or text messages (SMS). Think of all the technical components and frameworks that provide low-level services for the application.

✅ Dependency Inversion Principle

The essence of this definition is communicating that a component that provides low-level services (Infrastructure, for this discussion) should depend on interfaces defined by high-level components (for this discussion, User Interface, Application, and Domain). While there are several ways to express
an architecture that uses DIP, we could boil it down to the structure shown in Figure 4.3.

From the architecture of Figure 4.3, we would have a Repository implemented in Infrastructure for an interface defined in Domain.Focusing on the Domain Layer, using DIP enables both the Domain and Infrastructure to depend on abstractions (interfaces) defined by the domain model. Since the Application Layer is the direct client of the Domain, it depends on Domain interfaces and indirectly accesses Repository and any technical Domain Service implementation classes provided by Infrastructure. It may use any one of a few ways to acquire the implementations, including Dependency Injection, Service Factory, and Plug In [Fowler, P of EAA].

That's all for the Layers Architecture