1. IntroductionΒΆ
This guide provides practical guidance for migrating code from the event-processing framework art to Phlex. Before code can be expressed naturally in Phlex, it often needs to be simplified and reorganized.
art modules are typically written around an event-processing loop owned by the framework. Phlex encourages a different style: algorithms with clear inputs and outputs that can run independently of framework state. Reaching that style usually requires preparation work before any Phlex code is written.
The guide has three parts:
Framework and Domain Logic Separation identifies art constructs that should be removed, isolated, or reshaped before migration.
Algorithm Extraction refactors the code so the algorithm is defined in plain functions or small classes with no framework code in the algorithm itself.
Phlex Binding shows how an extracted design is expressed in Phlex concepts.
That order matters. Attempting to map heavily framework-entangled art code straight into Phlex usually produces awkward interfaces and preserves unnecessary complexity.
Throughout this guide, the framework boundary refers to the code that directly interacts with the framework: configuration lookup, input retrieval, service access, registration, and output publication. The goal of migration is to confine those operations to that boundary and keep the algorithm itself as ordinary C++.
This guide assumes the reader is familiar with existing art code and is working with an established code base that was not written with migration in mind. It also assumes migration may happen in stages. Separation and extraction work often yields simpler, more testable code even before Phlex code is written.
Because many existing code bases have limited test coverage, some migration work will require careful manual validation. The examples aim to make behavior-preserving algorithm extraction as explicit as possible.
