Skip to main content

Architecture Overview

Armatura is split into a small set of runtime layers with deliberately one-way dependencies. The point of the split is not tidiness for its own sake. It keeps three different concerns from bleeding into each other:

  • the structural engineering model,
  • the editor/runtime model,
  • and the desktop UI.

At a high level, the application is arranged like this:

SamLabs.Armatura.Editor
        ↓
SamLabs.Armatura.Engine
        ↓
SamLabs.Armatura.Core

There are supporting projects in the solution as well, but these three are the main runtime layers that shape how the application works.

SamLabs.Armatura.Core​

This module encapsulates the structural engineering domain and the analysis pipeline. It serves as the standalone computational engine of the Armatura system.

  • Domain Ownership: Defines all fundamental structural and design types, including models, members, nodes, supports, load cases/combinations, materials, and Eurocode evaluations.

  • Pipeline Management: Controls the complete solve path—from element creation and matrix assembly to solution execution and result recovery.

  • Headless Execution: Designed to run completely independent of the UI. Tests and automated workflows can interact directly with StructuralModel and ArmaturaProject.

  • Strict Boundaries: Maintains a rigid separation of concerns. Core has zero dependencies on Avalonia, ECS components, rendering systems, or viewport interactions.

SamLabs.Armatura.Engine​

This module serves as the interactive runtime and editor layer. It acts as the bridge between the user and the structural data, translating user actions into direct model modifications and real-time visual feedback.

  • Editor Infrastructure: Houses the foundational systems that drive the application, including the entity/component infrastructure, command system, and interactive tools.

  • Interaction & Visualization: Manages object selection, spatial manipulators, rendering-oriented components, and the core services required to operate the interactive viewport.

  • Core Integration: Directly references SamLabs.Armatura.Core to leverage structural concepts—such as members, loads, materials, sections, and analysis results—within the editor's features.

  • Architectural Boundaries: Enforces a strict unidirectional dependency. While the Engine is fully aware of the structural model, it guarantees that Core remains entirely oblivious to the editor's existence.

SamLabs.Armatura.Editor This module is the Avalonia desktop shell. It acts as the host for the editor runtime, presenting the UI chrome and managing desktop-specific operations. As the thinnest layer in the architecture, its primary job is coordination.

  • Application Wiring: Connects engine services, view models, UI panels, file dialogs, and application-level settings.

  • Desktop Coordination: Handles all OS and windowing concerns, wrapping the interactive engine in a functional desktop application.

Supporting Projects Several ancillary projects support the primary runtime layers without altering the core dependency architecture:

  • SamLabs.Armatura.CompositionCore: Provides shared framework and composition helpers.

  • SamLabs.Armatura.Geometry: Registers foundational geometry services utilized by the Engine.

  • Test Projects: Designed to exercise Core and integration pathways headlessly, entirely bypassing the desktop UI.

Dependency Architecture The system enforces a strict, unidirectional dependency graph: Editor → Engine → Core.

  • The Golden Rule: Core must never reference Engine or Editor. The structural model exists only to describe the structure, not how it is edited on screen.

  • Why It Matters: Preventing Core from knowing about UI selection states, ECS components, or viewport data ensures the structural analysis logic remains the stable, trusted center of the system.

  • Architectural Benefits: This strict boundary guarantees that Core remains highly testable, easily reusable, and completely immune to breaking when UI or rendering paradigms change.

Composition & State Management The architecture is designed for flexibility, relying on how components are assembled rather than rigid boundaries.

  • Composition-Based Reuse: The current desktop app is just one possible assembly of the runtime pieces. The true point of reuse is the composition root: different tools, modules, and services are registered at startup depending on the specific needs of the application.

  • Dual Sources of Truth: State is intentionally split to serve two distinct purposes, avoiding a "god object" anti-pattern:

    • Interaction: The Editor/Runtime model is authoritative for user interaction, presentation, and editing state.

    • Analysis: The Core StructuralModel is authoritative for solving. When an analysis runs, a distinct structural model is constructed in Core, solved, and the results are handed back to the editor.