Skip to main content

State and Intent: Communication in Prism Architecture

Reading time: ~15 minutes

Introduction​

Effective communication between architectural layers is essential for maintaining clean boundaries while allowing data and operations to flow naturally. Prism Architecture uses a "package delivery" approach based on Intent and State objects, creating a consistent, efficient communication mechanism that preserves proper layer separation.

This document explains how State and Intent objects function as the primary communication mechanism in Prism Architecture, how they're organized, and how they flow between layers. Understanding this communication model is fundamental to implementing Prism Architecture successfully.

Core Communication Concepts​

The Package Delivery Model​

In Prism Architecture, communication follows a model similar to a postal service:

  • Package Templates: Type definitions in the Common Layer (like envelope designs)
  • Packages: State and Intent objects containing data (like sealed envelopes)
  • Sorting Centers: Architectural layers that process and route packages
  • Delivery Routes: Layer connections that define how packages move
  • Contents: The data carried within State and Intent objects

This model creates an intuitive way to think about how data and requests move through the architecture.

Intent: Upward Communication​

Intents represent requests or actions that typically flow upward through the architecture:

  • Purpose: Express what should happen, not how it should happen
  • Direction: Flow upward from lower layers to higher layers
  • Content: Self-contained objects with all necessary data
  • Handling: Processed by the appropriate layer based on type

Think of Intents as service requests moving up the organizational hierarchy.

State: Downward Communication​

State objects represent the current condition or data and typically flow downward:

  • Purpose: Communicate current conditions or operation results
  • Direction: Flow downward from higher layers to lower layers
  • Content: Complete data packages with all relevant information
  • Processing: Each layer extracts what it needs from State objects

Think of State objects as information packets distributed down through organizational levels.

Immutability Principle​

All State and Intent objects in Prism Architecture are immutable:

  • Once created, they cannot be modified
  • Changes require creating new objects
  • Ensures data integrity through the architecture
  • Prevents unexpected side effects

This immutability creates predictable, traceable communication patterns.

Common Layer as the Definition Point​

All Intent and State types are defined in the Common Layer, providing:

  • A single source of truth for communication interfaces
  • Accessibility to all layers that need the definitions
  • Consistency across the architecture
  • Prevention of dependency violations between layers

This approach keeps all communication type definitions in one place while allowing actual instances to be created in their appropriate layers at runtime.

Organized Structure for Intent and State​

To keep the Common Layer organized, Intent and State definitions follow a clear folder structure:

Each folder contains related Intent or State type definitions:

  • Base/: Core interfaces and abstract types
  • UI/: Types related to user interface actions and display
  • Application/: Types related to application operations
  • Data/: Types related to data operations
  • Response/: Types related to operation responses

This organization improves discoverability and maintainability of the communication types.

Intent Flow Example​

Intents typically flow upward through the architecture, representing user actions or requests:

Each layer either processes the Intent or forwards it upward, adding context as appropriate.

State Flow Example​

State objects typically flow downward, carrying operation results or current conditions:

Each layer extracts what it needs from the State object, transforming it for its specific context.

Layer-Specific Implementation​

Presentation Layer​

The Presentation Layer creates Intent objects and processes State objects:

The Presentation Layer primarily:

  • Creates Intent objects from user actions
  • Processes State objects from the Orchestration Layer
  • Extracts and transforms data for display
  • Updates the UI based on State

Orchestration Layer​

The Orchestration Layer processes Intent objects from Presentation and creates State objects:

The Orchestration Layer primarily:

  • Processes Intent objects from Presentation
  • Coordinates operations across Domain and Infrastructure
  • Creates or forwards State objects back to Presentation
  • Manages application workflows and processes

Domain Layer​

The Domain Layer typically works with method calls rather than Intent/State objects:

The Domain Layer:

  • Implements business logic through method calls
  • Works with entities and value objects
  • May generate domain events
  • Returns domain objects to the Orchestration Layer

Infrastructure Layer​

The Infrastructure Layer processes requests and creates State objects:

The Infrastructure Layer:

  • Processes requests from the Orchestration Layer
  • Accesses external systems and data sources
  • Creates State objects for responses
  • Transforms external data into domain objects

Cross-Layer Communication Examples​

Presentation → Orchestration​

Infrastructure → Orchestration​

Comprehensive Flow Example​

This example shows the complete flow of Intent and State through all relevant layers:

This illustrates the complete cycle of a request and response flowing through the architecture.

Benefits of the Package Delivery Approach​

This approach to communication in Prism Architecture offers several key advantages:

  1. Clean Architectural Boundaries: No layer dependency violations
  2. Reduced Transformation Overhead: Minimal data transformation between layers
  3. Clear Data Flow: Easy to trace how data moves through the application
  4. Single Source of Truth: All communication types defined in one layer
  5. Consistency: Uniform approach to all inter-layer communication
  6. Type Safety: Strong typing across layer boundaries
  7. Immutability Guarantees: Data integrity throughout the application

Implementation Guidelines​

When implementing this communication approach:

  1. Define All Types in Common: All Intent and State type definitions belong in the Common Layer
  2. Organize by Purpose: Use folder structure to organize by intended usage
  3. Clear Naming: Use descriptive names that indicate purpose (OrderIntent, ProductState)
  4. Immutability: Make all properties read-only
  5. Complete Packages: Include all necessary data in each object
  6. Selective Access: Access only relevant properties at each layer
  7. Minimal Transformation: Only transform data when necessary

Common Anti-Patterns to Avoid​

Creating Types Outside Common Layer​

Problem: Defining Intent or State types in implementation layers creates inconsistency and dependency issues.

Solution: Always define all Intent and State types in the Common Layer.

Mutable Communication Objects​

Problem: Mutable Intent or State objects can lead to unexpected changes during transit.

Solution: Make all Intent and State objects immutable.

Excessive Transformation​

Problem: Completely transforming data at each layer boundary creates unnecessary overhead.

Solution: Use the package delivery approach where each layer extracts only what it needs.

Direct Layer Access​

Problem: Bypassing the Intent/State pattern for direct layer access violates architectural boundaries.

Solution: Always use Intent and State objects for communication between layers.

Conclusion​

The "package delivery" approach to State and Intent in Prism Architecture provides an elegant, efficient communication mechanism between layers while maintaining proper architectural boundaries. By defining all communication types in the Common Layer and organizing them by purpose, we create a consistent system that allows data to flow naturally through the application.

This approach balances architectural purity with practical implementation, minimizing unnecessary transformation overhead while preserving the benefits of clean layer separation. By following these patterns, you can create a maintainable, scalable application architecture that supports your business needs while remaining flexible for future evolution.