Platform / Architecture
Architecture that helps teams start faster, ship consistently, and keep standards under control
Gumon Platform is designed to reduce repeated structural setup across projects by giving teams a production-ready baseline they can extend over time.
This architecture reference aligns cross-team design decisions. It does not force a single implementation style, but reduces delivery drift.
Layer
Application Layer
Handles business workflows and user-facing services with flexibility and low system fragility.
Layer
API Service Layer
Defines shared API contracts and integration standards for predictable cross-team collaboration.
Layer
Data Stream Layer
Supports high-throughput event streams, asynchronous processing, and observability.
Core Services
Reusable building blocks teams can adopt immediately
- - Gumon Core for baseline system structure
- - Auth / Access Control / Profile for identity and authorization
- - Notification / Schedule / Storage as reusable foundational services
- - CLI commands for bootstrap, configuration, operations, and extension
Platform Principles
Design principles that keep systems stable as teams scale
- - Open core that is practical and auditable
- - Shared standards across engineering, operations, and delivery teams
- - Scale-ready architecture with minimal repetitive setup
- - Documentation and practices are part of the product, not appendices
High-Level Architecture
What sits inside each layer
The diagram above shows how many layers there are and how they connect. This section goes one level deeper: what each layer is made of, what it is responsible for, and what business and engineering teams get out of it.
Cloud Server Zone
Data Stream Layer
Event Base
Keeps systems consistent by passing events between them, instead of letting each system read and write another system's database directly.
In this layer
- - Event streaming — a continuous flow of what happened across the platform
- - Data pipelines — the routes that transform and forward data between systems
- - Message brokers — the queue that guarantees messages are not lost in transit
- - Data synchronization — keeping the same records aligned across systems
What you get
New systems can be added without reworking the ones already running, because integration happens through events rather than direct database coupling.
Cloud Server Zone
API Service Layer
Ready to use
Pre-built business services exposed through APIs, so teams compose a new system instead of rewriting the same foundations on every project.
In this layer
- - Point of Sale (POS) — storefront sales and payment capture
- - Customer Relationship Management (CRM) — customer records and relationship tracking
- - Content Delivery System (CDS) — distributing content to its destinations
- - Content Management System (CMS) — authoring, editing rights, and publishing
- - Inventory Management System (IMS) — stock levels and goods movement
- - Production Order System (PO) — production orders and their status
- - Human Resource System (HRS) — people records and related processes
- - Case Management System (CM) — cases and issues tracked to closure
- - Booking Management System (BMS) — reservations and resource scheduling
What you get
A new engagement starts from services that already work rather than an empty repository, so most of the effort goes into the client's actual problem instead of repeated groundwork.
Client Zone
Application Layer
What users actually touch
The delivered applications. Each one calls only the services it needs from the API layer, nothing more.
In this layer
- - E-Commerce Platform — web and mobile for online sales
- - E-Learning Platform — online learning and course delivery
- - Factory ERP — plant and production administration
- - Call Center App — case intake and follow-up, including the LINE channel
- - Hotel Management App — booking and room operations
- - Hospital App — patient-facing services on mobile
What you get
The same platform underneath supports different products on top, and the application can change without disturbing the services behind it.
Shared across every layer
Identity & Access
Auth / Access Control / Profile — one identity and authorization model for the whole platform, so no project has to build sign-in again.
Shared Services
Notification / Schedule / Storage — foundational services every layer can call for notifications, scheduled tasks, and file storage.
Operations
CLI commands for bootstrap, configuration, operations, and extension — the same setup and maintenance steps across every team.
What this separation guarantees
An optional capability that is not ready must report itself as unavailable rather than bring the system down — which is what makes the layering more than stacked boxes on a diagram. Failure stays inside the layer it belongs to, and day-to-day work continues.
The items listed per layer are the reference set shown in the architecture diagram above. A given engagement adopts only the parts its scope requires.