Introduction
Transforming a legacy framework into a modern application poses significant challenges, especially when dealing with a highly customized Domain-Specific Language (DSL). This article discusses the complexities encountered during the transformation process and emphasizes the importance of grounding development in business logic.
Understanding the Legacy Framework
Legacy frameworks often come with unique DSLs that are tailored to specific needs but can lead to numerous issues:
- Inflexibility in adapting to new requirements
- Excessive workarounds needed to achieve desired functionality
- High maintenance costs due to convoluted logic
Our Framework is configured with several hundreds of XML files, describing the views and all the workflows of the business processes.
Leveraging Modern Tools
In our attempt to modernize our application, we utilized tools such as Cursor and Codex to automate the transformation of workflows. However, we quickly recognized a fundamental flaw:
- These tools often preserved the existing workarounds, perpetuating outdated logic.
- Instead of streamlining processes, we found ourselves burdened with unnecessary complexity.
For example our XML files describe processes in a linear fashion, one step after another. Each step is bound to a condition, whether or not the step gets executed. Some of these conditions are the same for several steps. This is an old design flaw in the schema of the XML files: there is no “if-else” structure in our framework.
The Pitfall of “Shit-In-Shit-Out”
Using a Large Language Model to convert existing workflows can lead to a “shit-in-shit-out” scenario. If the input is riddled with workarounds, the output will not take full advantage of modern frameworks like dotnet or Angular.
In our case, neither the developer nor the LLM recognized that these repeated conditions should be refactored into a simple if-else statement. Both, the developer and the LLM were missing the context: the developer was missing the idea of the business process and the LLM was missing the context of the design-flaws of our framework.
What we got (pseudo-code, no real example):
if ([$actortype]==[$APP:TeacherType]) {
// Step-01
}
if ([$actortype]==[$APP:StudentType]) {
// Step-02
}
if ([$actortype]==[$APP:TeacherType]) {
// Step-03
}What we actually needed (pseudo-code, no real example):
public class TeacherProcess {
public Excute(){
// Step-01
// Step-03
}
}
public class StudentProcess {
public Execute(){
// Step-02
}
}
process = null;
if ([$actortype]==[$APP:TeacherType]) {
StudentProcess = new TeacherProcess();
}
else if ([$actortype]==[$APP:StudentType]) {
StudentProcess = new StudentProcess();
}
process.Execute();As a result:
- Maintenance becomes cumbersome due to the retention of obsolete logic.
- Future scalability is compromised, limiting the application’s evolution.
Importance of Business Logic
One of the key takeaways from our experience is the critical role of business logic in any transformation project. Instead of merely converting existing workflows, a more effective approach involves:
- Defining clear use cases based on current business needs.
- Transforming these use cases into clean, maintainable code.
Starting from the ground up allows developers to leverage the full capabilities of modern frameworks, creating a robust and adaptable application.
Conclusion
Transforming a legacy framework into a modern application is a complex, yet manageable task when approached with a clear understanding of business logic. By focusing on use cases rather than preserving outdated workarounds, organizations can develop applications that are not only functional but also maintainable and scalable.
In our case the solution was not to use better tools or the latest technologies, but go one step back, rethink the core business processes and focus on the training of employees and colleagues regarding these processes.
