Architecture overview

OpenPlatform keeps business modules composable, shared services reusable, and systems outside Firefly behind adapters. The shape below is what you will see across firefly-oss repositories.

Read top to bottom. Experience calls domain. Domain calls core. Adapters are not a fourth layer; they are the boundary on the integration page.

The picture is the direction of a call. Repository names for each band are on the module pages. Examples of each prefix appear in the bands below.

Why the bands exist

A single deployable that mixes HTTP for channels, domain rules, and persistence becomes hard to change when one journey needs a different pace from another. OpenPlatform splits that work into three repository conventions so teams can evolve a bounded context without rewriting everything above or below it.

Adapters sit at the edge. Provider SDKs and institution cores stay out of domain services so you can swap a rail, a PSP, or a document store without rewriting every application that starts a payment or stores a signed agreement.

Service bands

Channels sit above; institution systems and providers sit behind adapters.

OpenPlatform service bands (firefly-oss)

Experience (exp-*)

Channel and journey APIs (BFF). Orchestrates domain calls for apps and portals.

• exp-onboarding
• exp-lending
• exp-accounts

Domain (domain-*)

Commands, queries, and process coordination for a bounded context.

• domain-customer-people
• domain-lending-loan-origination

Core (core-*)

Persistence and core APIs for the bounded context.

• core-common-customer-mgmt
• core-banking-ledger

Adapters and libraries

Ports to payment rails, PSPs, document stores, identity, and institution systems. Shared libraries use the library-* prefix.

• library-rails
• library-psps

Around those bands:

• Channels start a journey (apps, portals, partner surfaces).
• Process coordinates across modules (orchestration, workflows such as Weave).
• Shared / identity covers users, notifications, reference data, and related common services.

Repository naming for the service bands is summarised in the business modules catalogue.

Where the code lives

Public OpenPlatform modules, adapter libraries, firefly-parent, and this documentation hub live under firefly-oss.

OpenPlatform runtime and ownership

GitHub org

firefly-oss

Business modules, shared services, adapter libraries, firefly-parent, and this documentation hub.

Framework train

Jafly 26.10.19 (Spring Boot 4.1.1)

org.fireflyframework:fireflyframework-parent via com.firefly:firefly-parent. Security SPI, ECM ports, and related adapter modules ship in the Jafly reactor.

Commercial applications that compose these modules are published under other organisations; see the short cross-link on the ecosystem page. This architecture page stays on firefly-oss.

Business module ids

The website and this hub share the same OpenPlatform module ids:

customers, onboarding, products, agreements, distribution, accounts, payments, lending, risk, plus shared identity services.

See the business modules catalogue for purpose, coverage, and repository names.

Integration grammar

A journey step may touch several layers (channel, process, modules, core, third party). Third parties and legacy cores stay behind adapters so provider details do not leak into every application.

Read top to bottom. Services call a port. The port is either payment providers or payment rails. Only the adapter talks to the outside system.

The provider port is PspAdapter in library-psps (payments, refunds, payouts, and further operation ports). The rail port is RailAdapter in library-rails (payments, settlement, mandates, and further operation ports, including a screening port). Those names live in the libraries. The picture keeps the words a reader needs.

Worked adapter guides:

• Adapter pattern
• PSP library (library-psps)
• Payment rails library (library-rails)

APIs and events form the backbone between modules. See the OpenAPI index and Event contracts.

AI stance

Where AI participates in a journey, it decides within approved limits, explained, recorded, and open to human review. Decisions with significant effects on people, or beyond delegated limits, go to people with delegated authority. Platform documentation must not describe AI as replacing staff outside those limits.

Runtime pin (brief)

OpenPlatform modules currently consume Boot 4.1.1 via fireflyframework-parent 26.10.19 (Java 25). See Versioning and BOM. Framework bootstrap and SPI usage: Jafly docs.

What next

1. Start here to navigate this hub.
2. Module catalogue to pick a bounded context.
3. OpenAPI index for published contracts.