Backend Architecture

Architecture Goals

The backend is organized around device access, business management, data processing, rule automation, message notification, and video capabilities. Modules collaborate through interfaces, messages, and caches. The design supports quick deployment while leaving room for future domain-oriented splitting and extension.

Layered Structure

Main Module Responsibilities

Domain	Responsibility	Typical Scenario
Controller layer	Expose REST APIs, validate parameters and permissions, wrap responses	Frontend queries for devices, products, rules, and alarms
Business service layer	Handle domain logic for devices, products, thing models, tenants, and permissions	Device creation, assignment, disabling, command delivery
Protocol layer	Access MQTT, CoAP, HTTP, Modbus, SIP, JT808, and other protocols	Device reporting, command delivery, gateway collection
Messaging layer	Process queues, bridges, async tasks, and device events	Traffic shaping, forwarding, rule triggering
Rule engine	Trigger actions based on device data, scheduled tasks, and alarm states	Scene automation, alarm recovery, message resend
Notification module	Unify notification templates, channels, and sending records	SMS, email, WeCom, DingTalk, system messages
Video module	Integrate with ZLMediaKit for stream pulling, playback, recording, and callbacks	Video monitoring, voice intercom, recording management

Device Business Flow

Key Design Points

• Permission isolation: device, product, organization, role, and menu permissions must be validated consistently to prevent cross-tenant access.
• Protocol extension: when adding a protocol, reuse protocol parsing, the message model, topic conventions, and device authentication flow where possible.
• Asynchronous processing: device reports, rule triggers, notifications, and video callbacks should be asynchronous to reduce request blocking.
• Cache strategy: use cache for hot data such as device status, thing models, Modbus configuration, and OTA tasks to reduce database pressure.
• Observability: business logs, protocol logs, rule execution logs, and notification logs should be traceable.

Secondary Development Suggestions

1. When adding device capabilities, confirm the product thing model and topic/protocol conventions before implementing controllers and services.
2. When adding a protocol, complete parsing and message conversion first, then connect it to the rule engine and data storage.
3. When adding a notification channel, use unified templates, sending records, and retry mechanisms.
4. When changing permission or tenant logic, verify list, detail, batch-operation, and export APIs together.