Logo
ScienceStack
Table of Contents
Fetching ...
Sign In

Reusability in MLOps: Leveraging Ports and Adapters to Build a Microservices Architecture for the Maritime Domain

Renato Cordeiro Ferreira, Aditya Dhinavahi, Rowanne Trapmann, Willem-Jan van den Heuvel

TL;DR

<3-5 sentence high-level summary> This experience report addresses building a maritime anomaly-detection MLES using Ports and Adapters within a Hexagonal Architecture. It proposes a monorepo-driven, microservices approach enabling multiple end-to-end services from a single codebase, with explicit data flows across Data Ingestor, Data Processor, Data Loader, Anomaly Detector, and API. It discusses challenges in generality and separation of concerns and distills lessons on compatibility, extensibility, and incremental development to guide future reusable, domain-specific MLES architectures. The work provides practical guidance for engineers implementing scalable, reusable MLES in the maritime domain and demonstrates how architectural patterns can accelerate parallel development across teams.

Abstract

ML-Enabled Systems (MLES) are inherently complex since they require multiple components to achieve their business goal. This experience report showcases the software architecture reusability techniques applied while building Ocean Guard, an MLES for anomaly detection in the maritime domain. In particular, it highlights the challenges and lessons learned to reuse the Ports and Adapters pattern to support building multiple microservices from a single codebase. This experience report hopes to inspire software engineers, machine learning engineers, and data scientists to apply the Hexagonal Architecture pattern to build their MLES.

Reusability in MLOps: Leveraging Ports and Adapters to Build a Microservices Architecture for the Maritime Domain

TL;DR

<3-5 sentence high-level summary> This experience report addresses building a maritime anomaly-detection MLES using Ports and Adapters within a Hexagonal Architecture. It proposes a monorepo-driven, microservices approach enabling multiple end-to-end services from a single codebase, with explicit data flows across Data Ingestor, Data Processor, Data Loader, Anomaly Detector, and API. It discusses challenges in generality and separation of concerns and distills lessons on compatibility, extensibility, and incremental development to guide future reusable, domain-specific MLES architectures. The work provides practical guidance for engineers implementing scalable, reusable MLES in the maritime domain and demonstrates how architectural patterns can accelerate parallel development across teams.

Abstract

ML-Enabled Systems (MLES) are inherently complex since they require multiple components to achieve their business goal. This experience report showcases the software architecture reusability techniques applied while building Ocean Guard, an MLES for anomaly detection in the maritime domain. In particular, it highlights the challenges and lessons learned to reuse the Ports and Adapters pattern to support building multiple microservices from a single codebase. This experience report hopes to inspire software engineers, machine learning engineers, and data scientists to apply the Hexagonal Architecture pattern to build their MLES.

Paper Structure

This paper contains 21 sections, 3 figures.

Table of Contents

  1. Introduction
  2. Fundamentals
  3. Machine Learning--Enabled Systems (MLES)
  4. Hexagonal Architecture
  5. Related Literature
  6. Ocean Guard
  7. System Architecture
  8. Data Ingestor
  9. Data Processor
  10. Data Loader
  11. Anomaly Detector
  12. API
  13. Application Architecture
  14. Challenges
  15. Generality
  16. ...and 6 more sections

Figures (3)

  • Figure 1: System Architecture of the Ocean Guard tool. The diagram follows the notation introduced by Ferreira Ferreira:2025:PhD:MetricsOrientedArchitecturalModel, and is based on the previous publication about the Ocean Guard tool Ferreira:2025:OceanGuard:MLOpsWithMicroservices. Rectangles represent services, which execute continuously. Stacked rectangles represent pipelines, which execute on demand. Lastly, cylinders represent data storage. Components are connected by arrows. Black arrows with a hollow tip illustrate the execution flow. They start and end in a component. Labeled arrows represent the trigger that starts a workflow, whereas unlabeled arrows represent the continuation of an existing workflow. Colored arrows with a filled tip illustrate the data flow. They appear in two types: solid arrows going to and from a data storage represent write and read operations, respectively; dotted arrows represent a sync or async request-response communication between components. Components are colored according to the data they produce: data, labels, source code, executable artifacts, models, anomalies, and telemetry. The remaining standalone componentsorchestrate the execution of others. Components are grouped into subsystems, with backgrounds colored according to the teams responsible for their development. Numbers, roman numeralsand lettersare used as labels throughout \ref{['sec:system_architecture']}.
  • Figure 2: Data flow of the Ocean Guard tool.Red cylindersrepresent data storage, while green hexagonsrepresent services. Arrows from a service to a storage represent writes, whereas arrows from a storage to a service represent reads.
  • Figure 3: Reusability in the Ocean Guard tool. The monorepo template (\ref{['subfig:services_monorepo']}) can be used to implement five types of microservices (subfig:services_data_ingestorsubfig:services_api) via the Ports and Adapters pattern Martin:CleanArchitecture:2017. The purple hexagonrepresents the Business Logic, where Domain-Driven Design patterns Evans:DomainDrivenDesign:2003 are implemented. The blue hexagonrepresents the Dependencies, where yellow circlesrepresent the Ports and red circlesrepresent the Adapters. Rectangles illustrate external dependencies, where a green rectanglerepresents a Driving Dependency (which initiates actions in the service) while an orange rectanglerepresents a Driven Dependency (whose actions are initiated by the service). Solid arrows, going from a port to an adapter represent the inside-out dependency flow, going from the Core to the Ports then to the Adapters.