问题描述
我正在尝试恢复遗留系统的架构.这对我来说是新事物.到目前为止，我已经阅读了许多研究论文，其中大多数研究人员为此提出了框架和自动化工具.但我不知道如何从这些框架或工具中选择最好的.所有的研究都有一些共同的步骤，如逆向工程和正向工程.有人可以帮忙吗?开始遗留系统恢复架构的基础阶段是什么?基本步骤是什么?有什么指导方针吗?谢谢
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
推荐答案
在转换遗留系统时，您必须牢记技术和团队.您必须进行的更改将进入应用程序的核心，如果开发团队不参与更改，迁移将是一个漫长而缓慢的过程.
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.
改造遗留系统的关键是依赖注入和服务定位.第一步是安装一个依赖注入容器，并在容器中添加一个类(Logger 始终是一个很好的第一个服务).
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.
记录器替换是 DI 如何工作的一个很好的例子，所以向团队演示这个.确保团队彻底理解这些概念！其余过程在很大程度上取决于 DI 和服务位置.
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.
DI 容器打破了遗留系统中的紧密耦合，因此您可以分解事物.开始寻找可以将应用程序分解成更小的部分的接缝，这允许您引入单元测试.这也将为 DDD 迁移、微服务、EDA 或您计划的任何目标架构奠定基础.
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.
这篇关于如何恢复遗留系统的架构 (PHP)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！