MedMission editorial platform

Context

MedMission AISBL, a Belgian medical NGO, needs to present its missions to the public and let its own team publish and update that content without calling a contractor for every change.

Problem and constraints

• A public site and an editorial back office in one product, maintainable by a small team.
• Media (photos, videos) to process without slowing the site down.
• Mission data that needs governance: who publishes what, and what may be aggregated publicly.

Architecture decisions and trade-offs

Ten architecture decisions are recorded in the repository. The main ones:

• A modular monolith rather than microservices: one deployable unit for a small team, with explicit module boundaries so a module can be extracted later.
• An executable hexagonal architecture: layer dependency rules are checked by ArchUnit tests on every build, not just described.
• A purpose-built back office rather than a generic CMS: the mission editorial model is specific, and a CMS would have imposed its own.
• PostgreSQL as the source of truth for missions, with a separate worker for asynchronous media processing.

Security and delivery

• Jenkins pipeline: preflight checks, SemVer versioning, build and tests, then secret scanning, dependency analysis (SCA), static analysis (SAST) and SBOM generation.
• Container images are scanned before publication, then promoted to a GitOps repository: deployment goes through Argo CD, never through a manual command.
• Every run collects its evidence (reports, artefacts), so delivery can be audited afterwards.
• Coverage (JaCoCo) and mutation testing (PIT) are wired into the Maven build.

Data

A dedicated architecture decision covers data governance. The schema evolves through versioned migrations (ten so far), and the public mission report is computed in aggregate.

Results and current state

• Under active development and already deployed; latest tagged release v0.5.0.
• 10 architecture decisions and 52 test files in the repository.