Software Architecture

This chapter describes software architecture not as a collection of patterns, but as a set of principles that protect the business domain from technical volatility.

The goal of architecture, as presented here, is not optimization or scalability by default. Its primary role is to preserve clarity, independence, and long-term evolvability.

What We Expect from Software Architecture

Despite the variety of architectural styles and technologies, the expectations placed on architecture are surprisingly few and fundamental.

• NFA-agnostic business domain – functional components must never depend on or even be aware of non-functional infrastructure.
• Deployment-agnostic development – business functionality must be developed without committing to specific deployment strategies.

Business meaning must remain independent of technical execution.

The architecture therefore separates functional concerns from non-functional concerns. This separation allows non-functional components to handle execution without understanding the business meaning of the operations they run, while the business design remains stable as technical execution strategies evolve.

Everything else in this chapter serves these two expectations.

How These Expectations Are Achieved

Each architectural view introduced in this chapter addresses a specific dimension of the problem. Together, they form a coherent model rather than independent techniques.

• Distributed Architecture
  Explains why distribution must be optional, not mandatory, and why business design must precede deployment decisions.
• Use Cases Architecture
  Introduces isolation at the use case level, allowing functionality to evolve independently.
• Layered Architecture
  Separates responsibilities vertically, preventing business logic, data processing, and infrastructure from blending.
• Functional Architecture
  Defines how business behavior is expressed through states, transitions, and handlers.
• Non-Functional Architecture
  Describes how execution is coordinated without understanding business meaning.
• Runtime Handler Discovery
  Explains how functional components are located dynamically without creating coupling to deployment topology.
• Assemblies Architecture
  Shows how architectural intent is preserved down to physical binaries and deployment units.
• Data Architecture
  Explores how data is structured and accessed in a way that supports the separation of concerns and deployment flexibility.

What Comes Next

With the architectural foundation established, the next chapters move deeper into implementation techniques that respect these boundaries.

The focus shifts from structure to execution, and from architectural principles to concrete mechanisms.

 

Table of Content

 

---

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.