Assemblies Architecture

Assemblies Architecture answers a practical and often underestimated question: how should software be physically organized so that functional architecture remains independent, deployable, and evolvable?

This page intentionally avoids technical listings of DLLs, projects, or build scripts. Instead, it explains the architectural meaning of assembly boundaries and why they matter.

From Functional Architecture to Assemblies

In the previous chapters, functional architecture was defined as a composition of independent logical layers:

• State Logic
• Business Logic
• Data Processing Logic
• Data Access Logic

Each layer has a clear responsibility and communicates through explicit contracts. Assemblies Architecture is the physical reflection of this idea.

Assemblies are not about code reuse. They are about responsibility isolation and deployment freedom.

What an Assembly Represents

An assembly represents one responsibility within one use case.

Not:

• all business logic in the system
• everything related to a database

But:

• business logic of a specific use case
• state handling of a specific use case

This distinction is subtle, but critical.

Handler-Centered Organization

Each logical layer exposes its behavior through handlers:

• State Handlers select the active state
• Transition Handlers perform work inside a layer

Assemblies are therefore organized around handlers, not technical concerns.

A simple mental model:

• One use case
• One layer
• One type of handler
• One assembly

Registration Is a First-Class Concept

Non-functional architecture must be able to discover handlers and route execution without understanding business meaning.

For this reason, registration is separated from behavior.

Assemblies that contain handlers are paired with assemblies that register those handlers at runtime.

This keeps functional code clean, infrastructure concerns isolated, and runtime composition flexible.

Constants and Contracts Live Above Layers

Some elements must be shared across layers:

• State names
• Transition identifiers
• Use case contracts

These elements do not belong to any logical layer. They form a shared semantic vocabulary, not behavior.

Placing them in a dedicated assembly prevents circular dependencies and keeps contracts stable.

Data Transfer Is Not Infrastructure

Data objects are not part of non-functional architecture. They represent business facts in motion.

Data transfer assemblies exist to:

• carry strongly typed data across layers
• preserve intent during transitions
• allow serialization without leaking infrastructure concerns

This idea prepares the ground for the next chapter, where a modern alternative to classical DataSet-style communication is introduced.

Why This Structure Matters

This assembly model enables:

• independent development per use case
• independent evolution per layer
• deployment as a single unit, multiple services, or a hybrid

All without changing functional code.

Deployment becomes a configuration choice, not an architectural rewrite.

Summary

Assemblies Architecture is not about naming conventions or folder layouts. It is about preserving the intent of functional architecture all the way down to binaries.

When assemblies mirror responsibilities instead of technologies, software becomes understandable, evolvable, and deployment-agnostic.

Table of Content Software Architecture Previous: Runtime Handler Discovery Next: Data Architecture