Runtime Handler Discovery

In the previous pages, we separated functional architecture from non-functional architecture (NFA). Functional architecture defines business behavior through state handlers and transition handlers. NFA coordinates execution without understanding the business meaning of that behavior.

A practical question now appears: how does NFA locate the correct functional handler at runtime?

Non-functional architecture must be able to locate functional handlers without knowing where they are deployed.

Why Discovery Is Needed

A hosted product or use case may be composed of many independently deployed components. For example, each use case may provide its own handlers, and each tier may contain multiple transition handlers.

This structure can be represented as a grid: use cases horizontally and tiers vertically.

NFA must be able to route work to one specific handler inside this structure. If NFA depended on hard-coded addresses or direct references, the system would quickly become rigid and difficult to evolve.

The Handler Registry

To avoid hard-coded coupling, NFA relies on a registry.

A handler registry is a runtime catalog that answers a simple question - given a routing key, where is the handler that can process it?

The routing key is the same metadata already described in Functional Architecture, for example:

• Product code
• Use case name
• Logical layer name
• State name
• Transition name

The registry maps this key to an execution endpoint. That endpoint may be:

• a component inside the same process
• a component in another process on the same machine
• a component deployed on another server

The important point is that NFA does not care which of these is true. It only needs a reliable way to locate the handler.

Why “DNS” Is a Useful Analogy

In networking, DNS resolves a human-friendly name to a physical address.

A handler registry plays a similar role in a software product: it resolves a logical identity (routing metadata) to an execution location.

But unlike DNS, the registry is part of the application architecture. It is a mechanism that supports business process execution.

Discovery and Health

Discovery is not the same as health. A registered endpoint only means that NFA knows where a handler or tier is expected to be located. It does not automatically mean that the endpoint is currently available.

For distributed deployments, the discovery service may periodically call simple infrastructure operations such as Ping and HealthCheck.

• Ping verifies that the endpoint is reachable.
• HealthCheck verifies that the endpoint is usable.

This allows NFA to resolve only available endpoints and avoid routing transition execution to a server that is known to be unavailable.

The health check should remain infrastructure-focused. Business initialization still belongs to normal transition execution, such as an InitializeUseCase transition.

What This Enables

Once handler discovery exists, the architecture gains important flexibility:

• Use cases can be deployed independently.
• Tiers can be deployed together or separately.
• Handlers can be moved without changing functional code.
• The system can evolve toward distribution without redesigning functional architecture.

In other words, discovery protects independence. It allows the product to change its deployment shape without changing the business model.

Summary

Runtime handler discovery is an NFA capability. It allows NFA to route work to functional handlers using logical identity rather than hard-coded location.

In distributed deployments, discovery may also include simple availability checks. The discovery service can resolve endpoints, verify them with Ping and HealthCheck operations, and return only endpoints that are currently usable.

This is one of the key mechanisms that makes distributed architecture possible without forcing distribution as a requirement.

Table of Content Software Architecture Previous: Non-Functional Architecture Next: Assemblies Architecture

 

---

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.