...
Once the system is verified that data is flowing into the new service and we have started the process of vessel consolidation, the construction of a new Vessel search should be undertaken. New systems would be able to utilize this new API for all search capabilities and lay the groundwork needed to use Composite UI Microservices to decouple the UI changes into service approach (https://docs.microsoft.com/en-us/dotnet/architecture/microservices/architect-microservice-container-applications/microservice-based-composite-ui-shape-layout).
Phase 3:
Investigate and implement a registry service layer to consolidate the registry data and services. This would follow the same approach as the Phase 1 where the integration is both updating the existing and new services layer data.
...
The SRP defines the responsibility of a class as a reason to change and states that a class should only have one reason to change. As an example, consider a module that compiles and prints a report. Imagine such a module can be changed for two reasons. First, the content of the report could change. Second, the format of the report could change. These two things change for very different causes; one substantive, and one cosmetic. The single responsibility principle says that these two aspects of the problem are really two separate responsibilities, and should, therefore, be in separate classes or modules. It would be a bad design to couple two things that change for different reasons at different times.
(Wikipedia https://en.wikipedia.org/wiki/Single_responsibility_principle )
In the Common Closure Principle classes that change for the same reason should be in the same package. Perhaps, for instance, two classes implement different aspects of the same business rule. The goal is that when that business rule changes developers, only need to change code in a small number, ideally only one, of packages. This kind of thinking makes sense when designing services since it will help ensure that each business rule change should impact only one service.
(Wikipedia https://en.wikipedia.org/wiki/Package_principles)
Phase 4:
Assuming at this point that the new architecture and services built can do the work of one or more existing registry applications the team can either decide to continue to add more services or start to modernize the UI stack to better leverage the services layer while refining the capability of the existing services. A new UI later for the administration of the Registry process needs to be constructed to remove the dependence on the legacy monoliths. When the users can perform the basic duties using the new services the teams can then look at building a new online stakeholder Registry Intake process that does not rely on the forms, thus providing a full digital registry offering for Small and Large Vessel.
...