2

I am trying to recover architecture of a legacy system.This is something new to me.Up to now I have read many research papers where most of the researchers have proposed frameworks and automated tools for this.But I have no idea how to choose the best from those frameworks or tools.All of the researched have some set of common steps like reverse engineering and forward engineering. Can someone help on this? What is the ground stage to begin the recovery architecture of a legacy system? What are the basic steps? Is there any guideline? Thanks

Ira Baxter
  • 93,541
  • 22
  • 172
  • 341
sadisha nadiej
  • 324
  • 3
  • 12
  • Please remember to mark the question "answered" when you are satisfied – Brad Irby Jun 08 '18 at 20:13
  • Thanks for the help.I loss my google account and I coudn't access the stack due to that.Thanks for your help – sadisha nadiej Jun 11 '18 at 13:29
  • Your first problem is to define "architecture"; most people throw this word around but don't have a precise definition. With such a precise definition, you can then ask what approaches/tools are used to extract such an architecture. Mostly you'll be disappointed at the actual tooling available, a) because these tools are hard to build [and PHP the language makes it worse] and b) because there are so many different possible defintions of architecture. – Ira Baxter Jan 08 '19 at 11:59

1 Answers1

0

When converting a legacy system, you must keep in mind both the technology an the team. The changes you have to make will go to the core of the application, and if the dev team is not on board with the changes it will be a long slow migration.

The key to reworking a legacy system is dependency injection and service location. The first step is to install a dependency injection container and add a class to the container (the Logger is always a good first service).

Next step is to add a service locator. Constructor injection is the best approach for greenfield projects, but for legacy apps it's not possible at first. With the service locator you can access the injection container from anywhere, allowing service resolution where needed. With this in place you can sweep through and replace logger creation code with logger resolution code.

The logger replacement is an excellent example of how DI works, so demo this to the team. Make sure the team understands these concepts thoroughly! The rest of the process heavily depends on DI and service location.

The DI container breaks the tight coupling in legacy systems so you can break things apart. Start looking for seams where you can break the app into smaller pieces, which allows you to introduce unit testing. This will also lay the groundwork for a DDD migration, microservices, EDA, or whatever target architecture you have planned.

Brad Irby
  • 2,397
  • 1
  • 16
  • 26
  • Thanks for the help.I think now I have something to work on.I will go through these steps.It was a big help.I am sorry for the late reply as I could not login to the stack overflow account – sadisha nadiej Jun 11 '18 at 13:32