Overview of the Architecture

Purpose of This Page

This page presents the runtime view of Business Process Unit Architecture. Earlier chapters already explained why BPUA exists and how business process concepts map to software execution. The goal here is different: to show the major runtime participants that appear in the current code base and the responsibilities each of them carries.

The Main Runtime Shape

In the current implementation, a BPUA-based system is organized around several cooperating runtime elements:

BPUAPlatformBootstrapper - starts the platform, loads configuration, resolves the plugin folder, initializes the application singleton, registers built-in services, and prepares dynamic use case activation.
BPUAApplication - acts as the process-local coordinator. It owns the service registry, holds application configuration, exposes use case activation, and dispatches service requests raised by state and transition handlers.
ServiceRegistry - stores registered types, registered objects, assembly processing facets, and state-to-transition information.
RequestHandler - base class for state handlers and transition handlers.
TransitionContextRouter - receives a request-to-next-layer event, calculates the next layer, resolves the matching transition handler, and forwards the transition context to the resolved transition handler.
UseCaseActivator - loads a requested use case on demand and makes its services available in the registry.

Conceptual Runtime Diagram

At a high level, the runtime flow can be understood like this:

Host application
    ↓
BPUAPlatformBootstrapper
    ↓
BPUAApplication
    ↓
ServiceRegistry
    ↓
RequestHandler / TransitionHandler
    ↓
TransitionContextRouter
    ↓
Next application layer

This diagram is intentionally simple. The important idea is that the host does not know the business functionality of each use case assembly. The platform itself owns activation, registration, and routing.

What Makes the Architecture Distinct

The current implementation shows several architectural decisions clearly:

The host application is lightweight. It starts the runtime but does not statically wire every use case.
Business functionality is loaded through assemblies rather than through direct project references from the host.
Transition execution advances by layer progression rather than by controller-to-controller calls.
Service discovery is registry-based, which allows plugins and platform services to follow the same lookup mechanism.

Type-Based Registration and Deferred Activation

One of the important architectural differences in BPUA is that the runtime is not centered on building one large, always-resident graph of service objects. Instead, the platform keeps a catalog of executable responsibilities. The service registry mainly records which implementation type corresponds to a given service key, and actual object creation is deferred until execution reaches that capability.

This distinction matters in large business systems. A platform may contain hundreds or thousands of handlers, processors, and supporting services, while only a small subset is exercised in normal daily work. Much of the remaining functionality may exist for occasional CRUD operations, reference tables, administrative maintenance, or specialized business flows. In that kind of system, activation on demand is more economical than organizing the application around broad resident object graphs.

Registration Order and Architectural Coupling

In object-centric composition, services are usually understood as parts of a dependency graph. Even when a dependency injection container permits flexible registration order, the architecture still tends to be organized around the availability of dependent objects. This makes composition more tightly coupled to construction concerns.

The BPUA service registry follows a different model. Its entries usually describe service identity and implementation type, not prebuilt object relationships. The registry records what capability is available under a given key, and actual object creation is deferred until execution requires that capability.

This reduces sensitivity to registration order. In many cases, entries can be registered independently and in any sequence, because registration does not itself require the entire dependency chain to be constructed. The main requirement is simply that all necessary types and supporting services are available by the time activation occurs.

This characteristic is especially valuable in modular platforms and plugin-based business systems, where assemblies may be discovered dynamically and where many capabilities are rarely used. It allows the application to compose a large catalog of executable responsibilities without forcing startup logic to mirror the dependency graph of the entire runtime.

Relationship to Earlier Chapters

This page does not redefine the meaning of business state, transition context, or finite state progression. Those topics are already covered in earlier chapters. Here they appear only as runtime participants: the architecture needs a concrete coordinator, a registry, handlers, and routing so that the conceptual process model can become executable software.

Summary

The current BPUA code base already expresses a clear platform structure. Bootstrapping prepares the runtime, the application singleton coordinates it, the registry stores what is known, activation loads what is missing, and routing advances the transition through the architectural layers.

Table of Content BPUA Chapter Next: Structure of a BPUA Application

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.