Skip to content

PSS®X Architecture

This section is providing you with an overview of PSS®X architecture and the general concept that are applied.

PSS®X base on ABP framework therefore it designed to support to build fully modular applications and systems where every module may have entities, services, database integration, APIs, UI components and so on

The figure below shows a typical request flow for a web application that has been developed based on DDD patterns.

  • The request typically begins with a user interaction on the UI (a use case) that causes an HTTP request to the server.
  • An MVC Controller or a Razor Page Handler in the Presentation Layer (or in the Distributed Services Layer) handles the request and can perform some cross cutting concerns in this stage (Authorization, Validation, Exception Handling, etc.). A Controller/Page injects the related Application Service interface and calls its method(s) by sending and receiving DTOs.
  • The Application Service uses the Domain Objects (Entities, Repository interfaces, Domain Services, etc.) to implement the use case. Application Layer implements some cross cutting concerns (Authorization, Validation, etc.). An Application Service method should be a Unit Of Work. That means it should be atomic.

Most of the cross cutting concerns are automatically and conventionally implemented by the ABP Framework and you typically don't need to write code for them.

Application Core Organization

The Application Core is the heart of the system, containing the business logic and domain model. It is designed to be independent of external frameworks, databases, and UI layers, ensuring maintainability, testability, and flexibility. The core is organized into the following components:

  • Domain Layer:

    • Contains the core business logic and domain model.
    • Includes entities, value objects, aggregates, and domain services.
    • Enforces business rules and invariants.

  • Application Layer:

    • Orchestrates the use cases and workflows of the system.
    • Contains application services, command handlers, and query handlers.
    • Mediates between the domain layer and external layers (e.g., UI, infrastructure).

  • Contracts (Ports):

    • Defines interfaces (ports) for external interactions, such as repositories, messaging, or third-party services.
    • Ensures the core remains decoupled from external implementations.

  • CQRS Separation:

    • Commands: Handle write operations, modifying the state of the system.
    • Queries: Handle read operations, retrieving data without modifying state.
    • This separation improves scalability and performance.

  • Cross-Cutting Concerns:

    • Includes logging, validation, and authorization logic.
    • Implemented in a way that does not pollute the core business logic.

  • Key Principles:

    • Dependency Inversion: High-level modules (e.g., domain logic) do not depend on low-level modules (e.g., infrastructure). Both depend on abstractions.
    • Testability: The core is designed to be easily testable, with minimal dependencies on external systems.
    • Modularity: Components are organized into clear, cohesive modules, making the system easier to understand and maintain.

References