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

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.