Domain responsibilities
Keep financial concepts and business workflows understandable, with explicit ownership of the rules and data involved.
Clear boundaries. Connected possibilities.
A reference view of how Firefly separates financial capabilities, application journeys, and the infrastructure around them.
Explore the architecture
A place for
every responsibility.
Follow the system from the experience to its operating foundation. Open each layer to understand its role.
This is a reference architecture. The services, external providers, and deployment topology are selected for each implementation.
01ExperiencesMeet customers and teams where they are.
Web and mobile experiences, partner portals, and operational interfaces connect to the platform. The channel is a deliberate choice for each business, independent of the core services underneath.
- Web & mobile
- Partner portals
- Operational tools
02ApplicationsTurn a business journey into a coordinated flow.
Application services expose business journeys through APIs and coordinate the work needed to complete them. Authentication, authorization, request handling, and process boundaries belong in the architecture from the outset.
- APIs
- Business journeys
- Access boundaries
03DomainsExpress the business in its own language.
Domain services coordinate business behavior across core services. Customer lifecycle, lending origination, and product pricing each have distinct responsibilities and explicit contracts.
- Customer lifecycle
- Lending workflows
- Product rules
04Core servicesGive each financial capability a clear home.
Dedicated modules handle accounts, ledger operations, payments, cards, lending, and shared platform data. Explore the individual repositories for their APIs, data models, and implementation details.
- Accounts & ledger
- Payments & cards
- Lending
05IntegrationCoordinate how the enterprise connects.
An integration boundary separates business processes from the details of external systems. Contracts, transformation, routing, and recovery behavior should be defined for each connection.
- Orchestration
- Data transformation
- Failure recovery
06External adaptersMake each external connection deliberate.
Adapters connect an implementation to its chosen providers and enterprise systems. The required networks, protocols, credentials, and operational responsibilities depend on the specific deployment.
- Provider connections
- Enterprise systems
- Explicit contracts
07InfrastructureBuild the operating foundation around the workload.
Services run with their required data stores, messaging, identity, and operational infrastructure. Deployment topology and controls are selected and validated for the intended environment.
- Data & messaging
- Runtime infrastructure
- Operational visibility
Architecture with intention
Connect the system.
Keep the business clear.
Integration contracts
Define what crosses each boundary, how failures are handled, and what an external dependency is expected to provide.
Operational context
Evaluate security controls, data management, observability, and recovery against the actual requirements of the deployment.
Discuss your next move
What needs
to change?
Tell us where you want to take your business and what stands in the way. We can help frame the opportunity, shape the roadmap, and define a practical first step.
Start a conversation