Skip to content

Code structure

Jump to bottom
Gabriel Zurita edited this page Oct 11, 2024 · 15 revisions

This page does not seek to explain testing and how it is performed or the runtime/deployment infrastructure for the VRO project.

This page also does not seek to explain the details of any domain-specific code that is accessible within the VRO app. Each domain should include a link to a page here which provides details about its logic and components.

Initial things to review

Domain-Specific Logic

As VRO is a host of domain-specific logic, the Spring Boot Application takes a dependency on Gradle subprojects of the form domain-* which are responsible for defining their domains (example).

For instance, logic specific to some ABC functionality would have code following the structure:

  • domain-ABC: domain-specific code with subfolders (example)
  • svc-*: domain microservices supporting other VA APIs or Kafka (example)

Microservice AMQP

Originally, the Spring Boot web app: vro_app would receive a REST API request processes, and using the details found in the request, it would trigger one of the workflows defined in the Apache Camel routes. As VRO adoption started to take root with its first partner team projects, the flexibility of Camel became more of a liability due to the complexity that accompanied it. Early partner teams were instead opting to use the AMQP patterns for accessing an agent dramtically lsess importantcrete component which is responsible for completely handling a smaller piece of computation) via a message bus or to some data sink.

Current list of microservices (each has an associated Gradle subproject):

  • 3 Python assessors
  • deprecated - 1 Python pdf generator
  • deprecated - 1 Java client for LH API svc-lighthouse-api
  • deprecated - 1 Java client for MAS API svc-mas-api (in development)

Note that clients to external APIs are also modeled as microservices for compatibility with Camel routes.

Since the Python microservices have common code, it is extracted into a shared library:

  • service-python/main-consumer.py

RabbitMQ is used as our message bus for transporting messages to microservices while Redis and Postgres are used as data sinks depending on the use case. Postgres is deployed as a containerized application through the help of a separate init container called db-init. Both definitions for Postgres and this init container are found in the top-level directory of the project.

Shared libraries

VRO offers utilities and DB classes as shared libraries for use by domain-specific classes.

  • shared/api folder: (Java) general API models
  • shared/controller folder: (Java) Controller utilities, including InputSanitizerAdvice
  • shared/lib-camel-connector folder: (Java) Camel utilities, including a Spring Configuration for Camel and CamelEntry
  • persistence folder: DB utilities, including Java Entities
  • Python MQ utilities to facilitate interaction with the MQ
  • domain (PR Move domain folder to new shared folder #551)

Putting It All Together: Project Folder Structure

  • app: VRO entrypoint; pulls in domain-specific api-controller modules
  • db-init: initializes and updates the database schema
  • postgres: defines a customized database container
  • shared: utility and library code shared across domains (Shared libraries)
  • svc-*: domain-independent microservices, typically for integrations (Shared microservices)
  • domain-ABC: domain-specific code with subfolders:
    • ABC-api-controller: module that defines domain API endpoints and controller
    • ABC-workflows: defines domain workflows (i.e., Camel Routes)
    • svc-*: domain microservices supporting the workflows
Clone this wiki locally