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 software product is composed of many independent components. For example, each use case may provide its own handlers, and each logic layer may contain multiple transition handlers.

This structure can be represented as a grid: use cases horizontally and logic layers 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.

What This Enables

Once handler discovery exists, the architecture gains important flexibility:

• Use cases can be deployed independently.
• Logic layers 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.

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