Functional Architecture

Business software exists to support business activity. Business activity is always expressed through data: money, customers, employees, orders, inventory, appointments, documents, and many other business entities.

Functional architecture (also called business domain architecture) is the part of a software product that works with this data and with the business processes built around it.

This page may look heavy because it ties together many ideas introduced earlier. The good news is that the structure is simple. Functional architecture is built on a small set of pillars.

The Six Pillars

• Physical separation of functional and non-functional architecture
• Data container for transferring data and metadata across layers
• State handlers that handle business process states
• Metadata used for routing requests to the correct handlers
• Transition handlers that perform work during transitions
• Handler isolation that preserves independence and deployability

Physical Separation

Functional architecture contains business behavior. Non-functional architecture (NFA) contains infrastructure: routing, composition, instantiation, communication, error handling, logging, security, and other technical concerns.

The separation is physical and strict:

• Assemblies belonging to functional architecture must not reference NFA assemblies.
• NFA assemblies may reference functional assemblies in order to serve them.

This rule protects the business domain from becoming infrastructure-dependent. The goal is an NFA-agnostic functional architecture.

Data Container

A data container transfers data and metadata between:

• functional and non-functional architecture components
• logical layers within a transition execution pipeline

This concept is inspired by the ADO.NET DataSet, but in a modern form: it transfers strongly typed objects and metadata and can be serialized (for example, as JSON) for communication. In the next chapter, this idea is explored further through the POCO DataSet approach.

State Handlers

A business process state is handled by a state handler. In an interactive application, the state handler is typically a page or component that:

• represents the current state to the user
• collects input
• raises triggers (button clicks, links, commands)

A state handler does not decide the next state. It only starts a transition by raising a trigger and providing input data.

Metadata

When a trigger starts a transition, the state handler places metadata into the data container. NFA uses this metadata to route the request to the correct transition handlers.

In this architecture, routing metadata consists of five parts:

• Product code – identifies the software product
• Use case name – identifies the use case
• Logical layer name – identifies the current pipeline stage
• State name – identifies the source state of the transition
• Transition name – identifies the transition

This metadata can be read as a routing key. It tells the system what kind of request it is and where it belongs.

Transition Handlers

A transition is executed by a sequence of transition handlers distributed across logical layers. Each handler performs its responsibility and either completes the request or passes it forward.

A transition handler is identified by the same five metadata values:

• Product code
• Use case name
• Logical layer name
• State name (source state)
• Transition name

When NFA receives a request (a data container), it uses routing metadata to locate the next matching handler. If a matching handler is not found at the current logical layer, NFA forwards the request to the next layer.

Handler Isolation

Handlers must be isolated from each other. A handler should not know that other handlers exist. It should work only with the data container assigned to it.

This isolation gives functional components real independence. It also preserves deployment flexibility: layers can be deployed together or separately, and the system can evolve toward distribution without redesigning the functional architecture.

Summary

Functional architecture is not a collection of patterns. It is a deliberate structure that keeps business behavior independent of infrastructure.

The six pillars described above make that structure practical: data and metadata are carried explicitly, routing is performed by NFA, and isolated handlers execute transitions through a stable pipeline.

Table of Content Software Architecture Previous: Layered Architecture Next: Non-functional Architecture