Business Process Unit Architecture (BPUA)

Introduction

Modern business applications rarely suffer from missing features. Instead, they become fragile when state becomes inconsistent, context leaks across screens, and business rules are enforced implicitly rather than explicitly. These problems usually appear when the architecture does not clearly define how business processes evolve, how state changes over time, and where authoritative context resides. These architectural weaknesses make it difficult to maintain correctness as systems evolve.

Enterprise systems must operate reliably over long periods of time. To achieve this, their architecture must make business process state explicit, bounded, and authoritative, so that process evolution, state transitions, and decision context remain consistent as the system grows.

Business Process Unit Architecture (BPUA) provides this foundation. Rather than organizing applications around pages, services, or CRUD operations, BPUA organizes them around Business Process Units — self-contained execution contexts that own their data, lifecycle, and transitions between business states.

This structure gives enterprise applications explicit business processes, clear boundaries, and authoritative context, allowing systems to evolve without losing correctness.

Why Many Application Architectures Become Fragile

Most application architectures evolve around technical layers:

• UI-driven navigation
• Service-oriented APIs
• ORM-centric persistence
• Implicit session or global state

In such systems:

• State is scattered across view models, services, caches, and databases
• Refreshing data often destroys in-progress user edits
• Partial updates are difficult to reason about
• Rollback and recovery logic becomes fragile
• Testing requires extensive mocking of hidden dependencies

These problems are not accidental — they are the result of implicit context.

What Is a Business Process Unit

A "Business Process Unit" (BPU) is a bounded execution context that represents a single business process or sub-process. It:

• Owns its business state
• Defines its allowed transitions between business states
• Controls how data is loaded, modified, merged, accepted, or rejected
• Exposes state changes explicitly to the UI

A BPU is not a page, a controller, or a service.

A Business Process Unit is the authoritative execution context for a bounded segment of a business process.

Core Principles of BPUA

1. State Ownership

Each Business Process Unit is the authoritative owner of its business process state.

2. Explicit Context

The context required to execute a transition is always passed explicitly.

3. Explicit Transitions

State changes occur only through well-defined transitions.

4. Deterministic State Evolution

For a given business state, transition, and context, the resulting state is deterministic.

5. Separation of Execution and Observation

Business logic mutates state. UI observes state changes.

Architectural Role of the Transition Context Container

When a business process transition is executed, the components involved in the execution must exchange the information required to perform that transition. This information includes business data, request metadata, routing identifiers, and other details describing the situation in which the transition must run.

In BPUA-based systems, this collection of information is referred to as the Transition Context.

A practical implementation requires a structured container capable of holding multiple related tables of data together with metadata describing the request. The container must allow different components of the system to exchange this information without repeatedly transforming it into incompatible formats.

Such a container typically provides:

• Schema-aware data tables
• Support for structured metadata
• Row-level state tracking for edited data
• Mechanisms for merging refreshed data
• Optional observable wrappers for user interface synchronization

Later sections of this site describe POCO DataSet, a structured data container that can be used to represent the Transition Context exchanged between BPUA components during transition execution.

Observable and Non-Observable Layers

BPUA distinguishes between:

• Execution layer — where business logic operates on plain datasets
• Observation layer — where UI components subscribe to state changes

This separation keeps business logic deterministic while enabling reactive user interfaces.

What BPUA Enables

• Explicit representation of business process execution
• Clear separation between process state, transition logic, and user interface
• Deterministic execution of business transitions
• Well-defined transition requests delivered to handlers
• Predictable and testable business workflows
• Reliable UI updates based on observable state changes

Summary

Business Process Unit Architecture is not a framework or a library.

Business Process Unit Architecture structures business applications around explicit process states and transitions.

By combining explicit context, deterministic transitions, and clear ownership of business process state, BPUA provides a foundation for complex, long-lived business processes — independent of UI technology, persistence strategy, or specific data container implementations.

Further Reading (BPUA)

• Context First Architecture
  From Business Processes to AI Agents
• Transition Execution in BPUA
  explains how those transitions are executed in software without losing correctness.
• POCO DataSet as Transition Context Container
  How BPUA uses POCO DataSet as the container that transports the data and metadata required to execute a business process transition.
• POCO DataSet as Structured Model Context Protocol (MCP) Context
  How POCO DataSet makes BPUA AI-ready by its nature.
• Using Model Context Protocol (MCP) within BPUA-based Systems
  Defines a standardized way for reasoning engines to receive structured context from BPUA-based systems.

 

Table of Content

 

---

Business Process Programming in .Net
© 2004–2026 Laskarzhevsky Software Inc.
Unless otherwise noted, the content of this website is licensed under the Creative Commons Attribution 4.0 International License (CC BY 4.0).
Code examples are provided under the MIT License.
You are free to share and adapt the material provided that appropriate credit is given and any modifications are clearly indicated.
The information provided on this website is for educational purposes only.
The author and publisher make no warranties regarding the completeness or suitability of the information and are not responsible for any damages resulting from its use.