Layered applications

The Suite Framework adheres to Clean Architecture and Domain-Driven Design concepts.

Domain-Driven Design, initially written in 2003 by Eric Evans, introduced new approaches towards designing software by using a layered architecture with a rich domain model in the center.

Uncle Bob wrote Clean Architecture in 2017 and summarized his research on what constitutes a clean architecture, also using a layered architecture with a domain layer in the center. The original article can be found here

Basics of Clean Architecture

Clean Architecture is an architecture following Uncle Bob’s principles. The key idea is to use the dependency inversion principle to place boundaries between high-level components and low-level components. This creates a “plug-in architecture” that keeps the system flexible and maintainable.

By employing clean architecture, you can design applications with very low coupling and independent of technical implementation details, such as databases and frameworks. That way, the application becomes easy to maintain and flexible to change. It also becomes intrinsically testable.

Benefits of clean architecture

• No dependencies on frameworks: the architecture is decoupled from third party frameworks
• Independent of UI: the architecture can be unplugged from the user interface
• Independent of database: the architecture is decoupled from the underlying data store.
• Independent of anything external: the business rules of the architecture are isolated and know nothing about the outside world.
• Testable

Layers of clean architecture

• User Interface (Presentation Layer): Provides an interface to the user. Uses the Application Layer to achieve user interactions.
• Application Layer: Mediates between the Presentation and Domain Layers. Orchestrates business objects to perform specific application tasks. Implements use cases as the application logic. It does not hold business logic.
• Domain Layer: Includes business objects and the core (domain) business rules. This is the heart of the application.
• Infrastructure Layer: Provides generic technical capabilities that support higher layers mostly using 3^rd-party libraries.

Separation of concerns

Please note in the next picture that Domain Layer at the center of the layered design. All dependencies are injected by DI, and no implementation details are known, as well as any other implementation detail are kept away from the higher layers. For example, IRepository abstractions are defined in Domain Layer, but they are implemented in a separated assembly, that belongs to the Infrastructure Layer.