Skip to main content

Layer Definitions in Prism Architecture

Reading time: ~12 minutes

Introduction​

Prism Architecture organizes an application into distinct layers, each with specific responsibilities and boundaries. This layered approach creates a clear separation of concerns while allowing for the practical flow of information and operations. Understanding these layersβ€”their purpose, components, and interactionsβ€”is essential for successfully implementing Prism Architecture.

This document defines each layer in detail, explaining their roles, key components, and relationships with other layers.

Core Layer​

The Core Layer forms the foundation of the Prism Architecture, containing the stable domain models and fundamental abstractions that define the application's essential concepts.

Purpose​

The Core Layer serves as the stable nucleus of the application by:

  • Defining the essential business entities and value objects
  • Establishing fundamental data structures used throughout the system
  • Providing core protocols that other layers implement
  • Creating a shared vocabulary for the entire application

Key Components​

  • Entities: Objects with distinct identity that represent significant domain concepts

    • Have unique typed identifiers (implemented as ValueObjectIDs)
    • Contain minimal behavior
    • Represent the primary domain objects

  • Value Objects: Immutable objects defined by their attributes

    • No identity of their own (equality based on all attributes)
    • Represent descriptive aspects of the domain
    • May contain validation logic related to their values
    • Include specialized ValueObjectIDs for type-safe entity identification

  • Enumerations: Define finite sets of related values

    • Represent conceptual sets (status types, categories)
    • Used across multiple entities
    • Stable and rarely changed

  • Core Protocols: Define interfaces that establish contracts

    • Define behaviors without implementation
    • Typically implemented in other layers
    • Create clear separation of concerns
    • Enable dependency inversion

Distinguishing Characteristics​

  • Most stable layer with infrequent changes
  • Accessible by all other layers
  • Contains no dependencies on other layers
  • Purely focused on domain concepts, not implementation
  • Uses strongly-typed identifiers through the ValueObjectID pattern

Domain Layer​

The Domain Layer implements business logic, validation rules, and domain-specific behaviors that define how the application's domain operates.

Purpose​

The Domain Layer serves as the business logic center of the application by:

  • Implementing business rules and validation logic
  • Defining how domain objects interact and operate
  • Encapsulating complex business processes
  • Enforcing domain invariants and constraints
  • Protecting the integrity of the domain model

Key Components​

  • Domain Services: Implement operations that don't belong to a single entity

    • Focus on business operations spanning multiple entities
    • Contain no state of their own
    • Express domain concepts not captured by entities

  • Validation Services: Ensure domain objects meet business rules

    • Focus exclusively on validation logic
    • Validate individual entities or complex object graphs
    • Return validation results rather than throwing exceptions

  • Rule Services: Implement dynamic business rules

    • Encapsulate business policies and decision logic
    • Can be configured based on business requirements
    • Focus on policy enforcement

  • Domain Events: Represent meaningful occurrences within the domain

    • Immutable records of domain occurrences
    • Named in past tense (e.g., OrderPlaced, UserRegistered)
    • Contain relevant event data
    • Enable reactive patterns within the architecture

Distinguishing Characteristics​

  • Contains business logic but not application flow logic
  • Depends only on Core Layer, not on other layers
  • Pure domain focus without infrastructure or UI concerns
  • Uses a rich domain model with behavior
  • Contains no direct external dependencies

Orchestration Layer​

The Orchestration Layer (formerly called the Application Layer) serves as the central coordinator in Prism Architecture, managing the flow of operations between all other layers.

Purpose​

The Orchestration Layer serves as the central coordinator of the application by:

  • Coordinating the flow of data and control between layers
  • Orchestrating complex operations that span multiple domain concepts
  • Translating between the needs of different layers
  • Managing system-wide reactions to domain events
  • Providing a coherent API for the Presentation Layer
  • Directing the appropriate use of Infrastructure services

Key Components​

  • Use Cases: Implement specific, focused operations on single entities

    • Handle atomic operations
    • Focus on single entity operations
    • Named with verb-noun combinations (e.g., RegisterUserUseCase)
    • Coordinate between Domain, Infrastructure, and Presentation layers

  • Orchestration Services: Manage related operations within a feature area

    • Can operate on multiple entities within the same aggregate
    • Compose multiple Use Cases within a feature domain
    • Named after feature domains (e.g., AuthenticationOrcService)
    • Maintain feature-specific context when needed

  • Workflow Coordinators: Manage complex, multi-step processes

    • Can work across different aggregates
    • Compose both Use Cases and Services from different domains
    • Handle complex processes with multiple steps or states
    • Manage state transitions throughout a process

  • Event Handlers: Respond to Domain Events

    • Subscribe to events from the Domain Layer
    • Coordinate system-wide responses to events
    • Direct appropriate actions in Infrastructure and Presentation layers

Distinguishing Characteristics​

  • Acts as central communicator between all layers
  • Organizes components hierarchically by complexity
  • Contains minimal business logic (delegates to Domain Layer)
  • Manages both command flow and event flow
  • Provides the main API for the Presentation Layer

Infrastructure Layer​

The Infrastructure Layer handles external communication, data access, and system services, providing the technical capabilities needed by the application.

Purpose​

The Infrastructure Layer serves as the technical foundation of the application by:

  • Implementing data persistence and retrieval mechanisms
  • Providing communication with external systems and APIs
  • Offering system-level services and capabilities
  • Implementing technical aspects of cross-cutting concerns
  • Supporting the needs of higher-level layers

Key Components​

  • Repositories: Provide data access and persistence

    • Implement Core Layer repository protocols
    • Handle data storage and retrieval
    • Manage transactions and data integrity
    • Abstract data source specifics from the rest of the application

  • API Clients: Communicate with external services

    • Handle HTTP requests and responses
    • Manage authentication with external systems
    • Format data for external communication
    • Handle connectivity issues and retry logic

  • Query Services: Optimize data retrieval for complex queries

    • Provide optimized data access across aggregate boundaries
    • Support GraphQL and other query patterns
    • Balance domain integrity with query performance

  • System Services: Interface with platform capabilities

    • Access device features and system APIs
    • Provide file system operations
    • Manage hardware interactions
    • Offer platform-specific functionality

Distinguishing Characteristics​

  • Focused on technical implementation rather than business concepts
  • Implements interfaces defined in Core Layer
  • Contains adapters for external systems and services
  • Provides GraphQL-optimized data access patterns
  • Isolates external technical concerns from the rest of the application

Presentation Layer​

The Presentation Layer is responsible for displaying information to users and capturing user input, providing the interface between users and the application.

Purpose​

The Presentation Layer serves as the user interaction point of the application by:

  • Displaying application data in a user-friendly format
  • Capturing and validating user input
  • Translating user actions into application operations
  • Managing UI state and transitions
  • Providing a responsive and intuitive user experience

Key Components​

  • UI Components: Visual elements of the user interface

    • Handle direct user interaction
    • Manage their internal visual state
    • Provide reusable interface elements

  • Presenters/ViewModels: Intermediaries between UI and application

    • Transform domain data into presentation-ready format
    • Handle UI-specific logic and state
    • React to user interactions
    • Communicate with Orchestration Layer

  • Screens: Complete user interfaces for specific functionality

    • Compose multiple UI components
    • Define layout and navigation
    • Connect UI components to presenters

  • Navigation Controllers: Manage transitions between screens

    • Handle screen transitions and animations
    • Manage navigation state
    • Coordinate deep linking and external navigation

  • UI State Management: Handle storing and updating UI state

    • Maintain UI state separate from domain state
    • Support undo/redo capabilities where appropriate
    • Manage transient UI states (loading, error, etc.)

Distinguishing Characteristics​

  • PrismUI follows a hierarchical presenter structure with three levels
  • Top-Level presenters access Orchestration Layer directly
  • Only Top-Level presenters can communicate with Orchestration Layer
  • Supports different UI patterns (PrismUI, MVVM, TCA, MVP)
  • Follows unidirectional data flow with state down, intents up

Common Layer​

The Common Layer houses cross-cutting utilities, data transfer objects, and shared functionality needed by multiple layers of the application.

Purpose​

The Common Layer serves as a shared utility and data transfer hub by:

  • Providing data transfer objects (DTOs) for communication between layers
  • Housing utility functions and helper classes used across the application
  • Defining common enumerations that aren't domain-specific
  • Supporting cross-layer factories for complex object creation
  • Offering tools for common tasks like validation and formatting

Key Components​

  • Data Transfer Objects (DTOs): Lightweight objects for data transfer

    • Simple data containers with minimal behavior
    • Optimized for data transfer, not domain logic
    • Tailored to specific communication needs
    • Typically mutable and serializable

  • Display Objects: Specialized DTOs for UI presentation

    • Contain presentation-ready data
    • Include UI-specific attributes
    • May combine data from multiple domain entities
    • Optimized for rendering efficiency

  • Utilities: Common functionality needed across layers

    • Stateless, reusable functions
    • Not tied to specific domain concepts
    • Focused on technical concerns rather than business logic

  • Cross-Layer Factories: Create complex objects spanning layers

    • Create composed objects from multiple sources
    • Handle object creation that doesn't belong to a specific layer
    • Support testing with standardized test objects

  • Common Enumerations: Non-domain-specific enumerations

    • Represent fixed sets of values used in multiple layers
    • Often related to technical or implementation concerns

Distinguishing Characteristics​

  • Accessible by Infrastructure, Orchestration, and Presentation layers
  • Not accessed by Domain Layer
  • Contains technical, cross-cutting concerns
  • Provides clear separation between domain entities and DTOs
  • More volatile than Core Layer, more stable than other layers

Optional Extended Layers​

For enterprise or large-scale applications, Prism Architecture can include additional specialized layers.

Security Layer​

  • Purpose: Centralizes authentication, authorization, and security concerns
  • Components: Authentication Services, Authorization Services, Encryption Services, Security Policies
  • Characteristics: Interfaces with identity providers, communicates with Orchestration Layer
  • Key Concept: Implements defense in depth with multiple layers of security controls

Configuration Layer​

  • Purpose: Manages environment-specific settings and feature toggles
  • Components: Configuration Management, Environment Management, Feature Flag Management
  • Characteristics: Enables different behaviors across environments
  • Key Concept: Feature flags allow for controlled deployment of new functionality

Comparing Layer Responsibilities​

Core vs. Domain​

  • Core Layer: Defines what things are (entities, value objects)
  • Domain Layer: Defines how things behave and interact

Domain vs. Orchestration​

  • Domain Layer: Contains business rules and logic (the "what" and "why")
  • Orchestration Layer: Controls application flow and coordination (the "when" and "where")

Orchestration vs. Presentation​

  • Orchestration Layer: Handles application operations and workflow
  • Presentation Layer: Manages user interface and interaction

Infrastructure vs. Common​

  • Infrastructure Layer: Implements technical services and external interfaces
  • Common Layer: Provides shared utilities and data transfer objects

Layer Access Rules​

Prism Architecture defines specific rules about how layers can access each other:

  1. Core Layer can be accessed by all other layers
  2. Domain Layer can only access Core Layer
  3. Orchestration Layer can access Core, Domain, Infrastructure, and Common layers
  4. Presentation Layer can access Core, Orchestration, and Common layers
  5. Infrastructure Layer can access Core and Common layers
  6. Common Layer can access Core Layer only

Conclusion​

The layered architecture of Prism creates clear separation of concerns while maintaining practical data flow. Each layer has well-defined responsibilities and boundaries, allowing for more maintainable and testable code. Understanding these layer definitions provides the foundation for implementing Prism Architecture effectively.