Links to most recent documents
Vessel Registry Infrastructure Readiness Microservice Architecture
Transport Canada’s Marine Safety and Security (MSS) have several applications designed to register and store vessel information, all of these systems are independent of each other and no data is shared nor common services used. The focus of this readiness review is on two core MSS systems: the Small Commercial Vessel Registry System (SCVRS) and the Ship Registry Computer System (SRCS), also referred to as Large Vessel Registry or the Canadian Register of Vessels.
...
The proposed approach is to be implemented in multiple stages to ensure the existing system will continue to function until enough services are built where then new UI and interfaces can be built to replace the legacy systems.
Phase 1:
Build a new service API for owner and vessel. In this case, the Owner service will be a newly branded service referred to as Stakeholder. The services will only contain what they need to do the intended job and not all existing database elements or functions may be required. The existing system will continue to function as currently designed updating all existing data elements. In this initial phase, the existing legacy systems will undergo modifications that will send Vessel and Owner transactions for creating and amendments to the new services to keep this data in sync between the old and new systems as well as a consolidation of the data into a single source of information.
...
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 the 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.
...