Structure of a BPUA Application

Introduction

One of the most important ideas in the current solution is that a BPUA application is not a single technical project. It is a composition of projects with different responsibilities. This separation is not cosmetic. It is the primary mechanism by which business functionality remains independent from execution infrastructure.

Functional and Non-Functional Parts

The project structure visible in the current code base naturally groups into three broad categories.

Functional Architecture

These projects define business-facing contracts and execution units:

• BPUA.Application.BusinessLogic - built-in business logic transition handlers such as application initialization.
• BPUA.Application.Contracts - interfaces, attributes, component names, transition handler contracts, and service registry contracts.
• BPUA.Application.Context - transition metadata, request metadata, and transition context support types.
• BPUA.Application.DataAccessLogic - built-in data access logic transition handlers.
• BPUA.Application.DataProcessingLogic - built-in data processing logic transition handlers.
• BPUA.Application.EventArguments - event argument types used by services and request routing.
• BPUA.Application.RequestHandlers - reusable request handler and transition handler base classes.
• BPUA.Application.Services - base service abstractions.

Non-Functional Architecture

These projects provide runtime infrastructure:

• BPUA.Application.Boot - configuration loading, assembly loading, service assembly processing, and boot orchestration.
• BPUA.Application.Orchestration - application singleton, routing, service registry, and orchestration helpers.

Common Projects used by FA and NFA

• BPUA.Application.Extensions.Services - service locator.
• BPUA.Core - identifiers, key compilation, breadcrumbs, assembly facets, and other low-level primitives.

Why the Split Matters

The practical benefit of this split is that the meaning of a business transition does not need to depend on how the system boots, how services are stored, or how assemblies are discovered. At the same time, the runtime infrastructure does not need to understand the business meaning of the transitions it routes.

Use Cases as Independent Units

The host solution contains the platform projects, while future business use cases are expected to be added as assemblies that conform to the contracts. The platform therefore becomes a reusable runtime shell rather than a monolithic business application.

Summary

A BPUA application is best understood as a layered collection of projects with explicit responsibilities. The separation keeps business logic stable while allowing boot, routing, scanning, and activation strategies to evolve independently.

Table of Content BPUA Chapter Previous: What Is a BPUA Application? Next: Platform Boot Process

 

---

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.