Splinter3D General Architecture

General Architecture

This Discussion is here to keep a track of Splinter3D's general architecture, every change in the folder organization / logic need to be documented here

[Kaiwinta]

First Refactor

Changes

Unlike the Prototype, Splinter3D is organized into layers. The fundamental rule: a layer depends only on the layers below it, never the other way around.

In src/:

app/            orchestration, startup, assembly
   ↓
ui/             presentation (windows, panels, widgets)
   ↓
application/    logic orchestration (commands, controllers, services)
   ↓
core/           UI ↔ logic mediation, central state, events
   ↓
geometry/       business domain (mesh, split, transform...)
rendering/      2D/3D display
platform/       OS-related concerns (files, config, threads...)

geometry/, rendering/, and platform/ are at the same level: they are independent domains, each depending only on core/ (and nothing above it).

Reason

• app/ contains only startup logic. If you put business logic or data managers there, the layer loses its purpose and becomes a catch-all.
• ui/ must never call geometry/ or rendering/ directly. It goes through application/ (triggering a command) and observes core/ (state, events) to update itself.
• core/ is the only layer allowed to be known by both ui/ and application//geometry//rendering/. It is the mandatory gateway, not a catch-all folder either.
• platform/ never knows anything about the layers above it. A PreferenceManager must never include a UI header.

Auxiliary folders

• tests/: unit/, integration/, end_to_end/ - mirrors the src/ structure but tests each layer in isolation, followed by their integration.
• third_party/: only if an external library is vendored directly into the repo (i.e., not via a package manager). - plugins/: intended for future extensibility; empty for now.

Notes

Each top-level subdirectory has its own README.md explaining what goes there and why.

Implementation

Implemented in #21