Data Architecture

So far, we have focused on how business processes are structured and executed: use cases isolate responsibility, layers separate types of work, and non-functional architecture moves work through the system.

All of these ideas depend on one practical question: what exactly moves through the system?

The answer is data. Not as database rows or UI fields, but as business facts in motion.

In this architecture, data is not a byproduct of execution. It is the medium through which execution happens.

Why Data Must Be an Architectural Concern

In many systems, data is treated as an implementation detail. Developers create one data shape for the database, another for the service layer, another for the user interface, and then spend much of the project converting between them.

This approach becomes fragile in process-driven systems, because:

• business processes run through multiple states and transitions
• data must survive and evolve as the process progresses
• execution may cross layers, modules, or deployment boundaries

If data loses meaning at each boundary, then business logic becomes dependent on how other layers represent data, and the architecture collapses into coupling.

The Problem with "DTO Chains"

A common anti-pattern in layered systems is a chain of conversions:

• UI model -> service model -> domain model -> persistence model

At each conversion point, meaning is reinterpreted. Fields are renamed, combined, split, or dropped. Over time, the system no longer has a single, stable representation of business facts.

In business process execution, this is especially dangerous because decisions depend on context. A decision is rarely based on one value. It is based on a set of facts collected over time.

Data Requirements in This Architecture

To support business process execution, data must have a small set of properties. These properties are architectural constraints, not implementation preferences.

• Self-describing – data must carry enough structure and metadata to preserve meaning.
• Layer-agnostic – the same data can be consumed by state handlers, business logic, data processing logic, and data access logic without being reshaped at each layer.
• Transition-safe – data must survive transitions without being fragmented into multiple incompatible forms.
• Serializable – data can be transported, logged, stored, or forwarded across deployment boundaries.
• Explicit – missing values and schema differences must be represented explicitly, not hidden in code.

These requirements ensure that business logic can remain focused on decision-making, rather than on reconstructing meaning from scattered representations.

Data and Non-Functional Architecture

Non-functional architecture coordinates execution without understanding business meaning. For that coordination to work, the unit of work must be transportable and routable.

This is why the architecture uses a data container: a transportable representation of business facts plus routing metadata.

The data container connects functional architecture and NFA. It allows the system to move work through layers and handlers without coupling business behavior to infrastructure details.

Bridge to the Next Chapter

This page described what data must be in a process-driven architecture. The next chapter describes one concrete realization of these principles: the POCO DataSet.

It is introduced not as a replacement for a database, but as a practical way to carry business facts safely through states, transitions, and layers.

Table of Content Software Architecture Previous: Assemblies Architecture