Sample architecture - aurigma/direct-mail-app-sample GitHub Wiki

Architectural boundaries of the application

The sample uses a classic three-layer architecture and an anemic domain model, where all business logic and infrastructure tasks are implemented in services, and models define the data structure.

The main layers of the application:

  1. Presentation layer. The presentation layer is responsible for processing incoming client requests and generating responses.
  2. Application layer. The application layer provides a set of available operations within the application. It includes data models and services that implement business logic and infrastructure operations.
  3. Data access layer, DAL. The data access layer is responsible for interacting with a specific DBMS and file system.

Application Components

The application includes the following components:

  1. App represents the Application layer. This component contains all the business logic of the application, as well as infrastructure transformations.
  2. DAL.EFCore refers to the DAL layer. This component is a facade over the Entity Framework Core and implements interfaces for interacting with the database.
  3. DAL.FileSystem refers to the DAL layer. This component organizes access to the file system.
  4. DAL.Postgres refers to the DAL layer. This component is responsible for interacting with the PostgreSQL DBMS.
  5. DomainEntities can be attributed to the Application layer. This component contains the domain data model of the application.
  6. WebAPI refers to the Presentation layer. This component provides an API for interacting with the application.
  7. WebHost refers to the Presentation layer and configures the application and all its components.

items

The application is built around business logic. The Application layer is independent. It contains a business model that includes domain entities, services, and interfaces. These interfaces include abstractions for operations such as data access, file system access, network calls, etc. Interaction with other layers occurs using Models.

The Web API uses its own Models and DATA, so the client determines what it receives and sends through the API, not the Application layer.

Basic terms

Domain entities (e.g. LineItem)

Define the data structure of the subject area and do not contain logic.

DAL Entities (e.g. LineItemDal)

Define the data structure that is used to store objects in the database.

Models (e.g. LineItemCreationModel)

Contain data for performing any operations. Their names reflect the essence of the operation and contain the postfix "Model".

DTOs (e.g. LineItemDto)

Data Transfer Objects (DTO) are used to transfer data and do not contain business logic. DTOs are independent of the context, no matter where they are used, they represent the state of domain entities.

App Services (e.g. LineItemAppService)

Provide a set of available operations for an external user (Presentation layer). They do not contain business logic.

The main requirement for App services is that they are independent of each other and are not available to other service types.

Domain Services (e.g. LineItemSerivce)

Include the core business logic of the application.

Repositories (e.g. LineItemRepository)

Used to encapsulate the logic of working with the data context class (e.g. DataContextFacade).

Adapters (e.g. TokenAdapter)

Used to interact with external services and systems.

Storage adapters (e.g. LineItemRepositoryAdapter)

Used to convert data from domain entities to DAL layer entities and vice versa.