Enterprise Management Platform
Lumira
Bring business collaboration onto one platform.
Lumira is a SaaS platform for enterprise management and event collaboration. It brings business modules for events, projects, competitions, experts, and workflows together with core capabilities for authentication, teams, files, and messaging.
Product Capabilities
Business modules and platform capabilities working together
Business Collaboration
Modules for events, projects, and competitions work with expert, team, and workflow capabilities to organize participants and business processes.
Events · Projects · CompetitionsShared Core Capabilities
Authentication, files, messaging, payments, internationalization, and plugins are separate modules that provide reusable platform capabilities across business domains.
Authentication · Files · MessagingTECHNOLOGY STACK
A complete stack, from interface to data
Interface Layer
React · TypeScript · Umi
Build modular business interfaces with typed page and data interactions.
Interaction and Data Requests
Ant Design · Pro Components · React Query
Reuse administration tables, forms, and layouts while managing request state and client-side data caches.
Application Layer
Java · Spring Boot · Maven
Organize domain capabilities, application interfaces, and infrastructure implementations in a modular codebase.
Persistence and Migrations
MySQL · MyBatis-Plus · Flyway
Manage business data, data access, and versioned database schema changes.
State and Events
Redis · Redis Streams · Outbox
Support session and authorization state, rebuildable caches, and background event processing.
From the interface to business logic and background tasks
The frontend accesses Server through synchronous APIs. Business modules collaborate through application ports within Server; Async and Job Executor access business capabilities through authenticated internal interfaces. Server exclusively owns access to the business database.
lumira-server
Application ports and contracts connect modules through unified MySQL access
How a business operation is completed
For a request requiring subsequent asynchronous processing, the synchronous response and background work follow separate paths.
- 01
Submit an Operation
A user completes a form or initiates an operation, and the frontend submits a request to the server.
- 02
Verify Identity and Permissions
The server checks the session and authorization versions, applying access rules for the current user, roles, and data scope.
- 03
Execute Business Logic
The application layer calls the relevant business module, validates business rules, and saves results through a shared data-access entry point.
- 04
Process Follow-up Events
Asynchronous work enters the event-processing path for relay or consumption by Async; scheduling handles recovery from failures.
Technical Architecture
A modular business system with clear responsibilities
Lumira uses a modular monolith: business domains collaborate within one server, while separate runtime units handle asynchronous processing and scheduled jobs. Modules exchange data through explicit application interfaces, separating business logic, infrastructure, and runtime responsibilities.
Frontend: Consistent Business Interactions
The administration interface uses React, TypeScript, and Umi, with Ant Design and Pro Components for forms, tables, and business layouts. React Query manages server requests and caching. Interface components and data access are organized separately so multiple modules can reuse consistent interactions.
Backend: Modules Organized by Business Domain
The backend uses Java, Spring Boot, and a Maven multi-module project covering events, projects, competitions, experts, teams, payments, files, and messaging. Modules collaborate through application ports and shared contracts rather than depending on other modules' internal controllers, entities, or data-access implementations.
Data: Clear Ownership and Access Points
MySQL stores business data, with MyBatis-Plus providing persistence access. Server exclusively accesses the business database; asynchronous and job-execution units call business capabilities through internal application interfaces. Tables and migrations have recorded module ownership, establishing clear responsibility for schema changes.
Caching: Separate Runtime State from Rebuildable Data
Redis serves two purposes: runtime state and caching. Sessions, permission versions, and message streams use a dedicated instance, while regenerable caches use another, keeping data with different reliability requirements out of a shared cache lifecycle.
Identity and Permissions: Authorization That Follows Business Changes
Authentication associates JWTs with server-side session state. Authorization versions separately track user status, role and department assignments, role permissions, and data-scope policies. When permissions change, affected sessions are revalidated on subsequent requests, limiting disruption to unrelated users.
Asynchronous Processing: From Business Events to Background Execution
Async handles Outbox relay and Redis Streams consumption. Different event domains use separate execution channels, bounded queues, and circuit-breaker state to limit the impact of slow requests. Job Executor handles scheduled compensation and manual replay.
Plugins: A Traceable Extension Lifecycle
Plugins move through validation, migration, runtime verification, and activation states, with failures recorded separately. Digests link plugin packages to migration content. A dedicated migrator performs database schema changes, while the business application manages plugin control and state.
Engineering Constraints: Keeping Module Boundaries Effective
Maven metadata, Enforcer rules, and architectural boundary tests constrain dependencies. Domain code is separated from web, database, and cache implementations. Shared libraries do not depend back on business modules, reducing implicit coupling as features grow.
Three Runtime Units with Distinct Responsibilities
Business and Control Center
Receives synchronous API requests, assembles business modules, performs authentication, authorization, and business processing, and provides unified access to the business database.
Events and Asynchronous Processing
Handles routine Outbox relay and stream consumption, executing business operations through authenticated internal interfaces without reading the business database directly.
Scheduling and Recovery
Handles scheduled tasks, compensation, explicit replay, and recovery separately from routine asynchronous message processing, avoiding duplicated relay responsibilities across runtime units.
Explore Lumira and Start Building
Learn more about modules, technical implementation, and project progress.