(Clean Architecture) Application Layer

Copyright

이 모든 내용은 Pluralsight에 Matthew Renze가 올린 'Clean Architecture: Patterns, Practices, and Principles'라는 강의의 세번째 챕터를 듣고 정리한 것입니다(https://app.pluralsight.com/library/courses/clean-architecture-patterns-practices-principles/table-of-contents). 저작자님께 게시허가도 받았습니다.

Content

1. Clean Architecture

2. Domain-centric Architecture

3. Application Layer 

4. Commands and Queries (CQRS)

5. Functional Organization

6. Microservices

7. Testable Architecture

8. Evolving the Architecture

Outline

Application Layer

Dependency Inversion Principle

Pros and Cons

What are Layers?

Layers are boundaries or vertical partitions of an application designed to represent different levels of abstraction, maintain the single responsibility principle, isolate developer roles and skills, help support multiple implementations, and assist with varying rates of change.

Essentially, layers are the way that we slice an application into manageable units of complexity.

Classic Three-layer Architecture

User interface Layer : provides the user with an interface into the application 

Business Logic Layer : contains the business logic of the application

Data Access Layer : contains the logic to read and write to the database.

Modern Four-layer Architecture

Presentation Layer : provides the user with an interface into the application

Application Layer : embeds the use cases of the application as executable code and abstractions

Domain Layer : contains only the domain logic of the application

Infrastructure Layer : oftentimes it makes sense to divide this layer into one or more projects

e.g. common variation is to create a separate project for persistence, and a separate project for the remaining infrastructure. In diagram on the left create Persistence project to provides the application with an interface to the database or other persistent storage.

Cross-cutting Concerns Layer : aspects of the application that cross all the layers of the system

Application Layer

Implements use cases as executable code

e.g. a customer searches for a project, adds it to their cart, and pays with a credit card.

High-level representations of application logic.

e.g. a query that searches for our project for our customer or a command that adds a product to their shopping cart.

The application layer knows about the domain layer, that is, it has a dependency on the domain, but it does not know about the presentation, persistence or infrastructure layers(no dependencies on the outer layers of the application).

The application layer, however, does contain interfaces for its dependencies that these respective outer layers then implement. Then we use an IoC framework(inversion of Control framework) and dependency injection to wire up all the interfaces and their implementations at run time.

We can follow the flow of control through the application from the users at the top of the diagram down to the database and OS at the bottom of the diagram. In addition, we can follow the dependency arrows, which flow both upwards and downwards towards the domain.

Unlike classic three layer architecture, Persistence and Infrastructure layer depends on application layer. These inverted dependencies comes from the dependency inversion principle. It states that abstraction should not depend on details, rather, details should depend on abstractions. So in the persistence and infrastructure layers we implement the inversion of control pattern. That is, our dependencies oppose the flow of control in our application. This provides several benefits, such as providing independent deployability. That is, we can replace an implementation in production without affecting the abstraction that is depends upon. It also makes architecture more flexible and maintainable as well. For example, we can swap out our persistence medium and infrastructure dependencies without having negative side effects ripple throughout both the application and domain layers. This is highly useful for agile applications where we often defer implementation decisions as late as possible when we have a much better understanding of the specific needs of our application and its implementations. This it a strategy referred to in Agile software development as the last responsible moment.

Sometimes we need to add an additional dependency from the persistence project directly to the domain project when using an Object Relational Mapper(ORM). This is necessary for the ORM to map domain entities to tables in the database since the persistence layer needs to know about the entities contained int the domain layer. Using an ORM is optional when creating clean architecture, but it can save a tremendous amount of development time if used correctly.

Demo

In the Presentation project : SalesController that has a dependency on the ICreateSalesCommand interface in the application project.

In the Application project : CreateSaleCommand class implements ICreateSalesCommand interface and contains the high level application logic that fulfills the use case for creating a new sale. The class has a dependency on the IDatabaseService interface and IInventoryService interface both of which contained in the application project as well.

In the Persistence project :  DatabaseService class implements the IDatabaseService interface

In the Infrastructure project : InventoryService class implements the IInventoryService interface.

All of the dependencies point towards the application and thus transitively towards the domain. All of the details, that is implementations, depend upon abstractions, which are interfaces, and we utilize inversion of control for both the persistence and Infrastructure projects dependency on the application project.

Cross-cutting concerns are a bit different, as there are typically multiple projects that all have dependencies upon them. So Cross-cutting concerns project store both the interfaces and the implementations(IDateService interface and DateService class). Then multiple classes(CreateSaleCommand, SalesController, DatabaseService, Sale and InventoryService uses IDateService)

Why Use an Application Layer

Pros

Focus on use cases

Easy to understand

Follows DIP(Dependency Inversion Principle

Cons

Additional layer cost : Layers in software architecture are expensive to create and maintain

Requires extra thoughts : to separate application layer from domain layer

IoC is counter-intuitive

출처

이 모든 내용은 Pluralsight에 Matthew Renze가 올린 'Clean Architecture: Patterns, Practices, and Principles'라는 강의의 세번째 챕터를 듣고 정리한 것입니다(https://app.pluralsight.com/library/courses/clean-architecture-patterns-practices-principles/table-of-contents). 제가 정리한 것보다 더 많은 내용과 Demo를 포함하고 있으며 최종 Summary는 생략하겠습니다. Microsoft 지원을 통해 한달간 무료로 Pluralsight의 강의를 들으실 수도 있습니다.