iDaVIE Codebase Refactoring — EPIC Team Project

The assessment was a design-only refactoring proposal. No upstream code was changed: two teams — Alpha, 28 students, and Beta, 27 — spent 15 working days building competing proposals and pitched them to the iDaVIE maintainer panel, with the winning proposal to become the basis of a real refactoring effort. Construction was evidenced through worked design-level refactoring examples rather than commits. iDaVIE itself is a Unity VR application for exploring 3D astronomical data cubes: a single scene driven by MonoBehaviour scripts, performance-critical I/O in C/C++ native DLLs (FitsReader, DataAnalysis, AstTool), a GPU ray-marching renderer, a Feature system for regions of interest, two VR interaction state machines, and a desktop GUI alongside the VR view. The maintainability pressure is that domain logic and Unity lifecycle code are intermixed, and the Unity 6 migration would have to drag all of it along. Both teams targeted the same style, so the competition was over how well it was realised: client–server, with a micro-kernel server exposing a versioned, ABI-stable plug-in contract for the C/C++ extensions; a layered kernel of Domain → Application → Infrastructure → Plug-in host with strictly downward dependencies; and an anti-corruption layer around the Unity 6 APIs. Three constraints did most of the shaping — no unjustified SOLID or GRASP violation, no circular dependencies between top-level components, and no transitive dependency from domain code onto UnityEngine or SteamVR types. My sub-team owned the Feature domain. The central move is promoting Feature to a first-class domain aggregate in the kernel domain layer, independent of any Unity type, and splitting the existing FeatureSetManager into three: a FeatureCatalog holding persistence and identity, a FeatureSetService orchestrating the use cases, and a FeatureVisualiser as the Unity-side adapter. GRASP Information Expert puts the feature-derived statistics — voxel count, total and peak flux, flux-weighted centroid, W20 — on the aggregate that owns the data, and Liskov keeps masked, imported and user-defined features substitutable behind a single IFeature. Two worked examples carried the construction competency: moment-map generation, moving from a Unity script calling the DataAnalysis DLL directly to a use case on the server that returns a result, and VOTable export becoming a FeatureCatalog responsibility behind a clear export plug-in seam. The testability strategy pairs property-based tests over the statistics — centroid inside the bounding box, flux non-negative, W20 ≤ W50 — with a scenario test running mask → masked features → edited feature → exported VOTable.