Architecture at a Glance - nbacheng/nbcio-boot

Source Files

This page is generated from the following source files:

The nbcio-boot project is a modular enterprise application built on Spring Boot 2.3.5, designed with a multi-module Maven architecture that separates concerns across base infrastructure, business modules, and optional microservice starters. The architecture supports both monolithic deployment and microservice transformation, with integrated workflow capabilities through Flowable, real-time communication via WebSocket, and comprehensive system management features.

Project Structure Module Composition

The project follows a hierarchical Maven structure with clear separation between foundational components and business-specific modules. The parent POM orchestrates six primary modules that form the application's backbone.

正在加载图表渲染器...

Key Architecture Points:

Modular Hierarchy: The parent POM defines all modules including base, system, flowable, IM, and estar modules (pom.xml:55-65), enabling independent development and testing of each component.
Base Layer Abstraction: The base module splits into three sub-modules—api, core, and tools (nbcio-boot-base/pom.xml:15-19)—providing a clean separation between API contracts, core implementations, and utility functions.
System Module as Entry Point: The system module serves as the main application entry, integrating all business modules including demo, estar, and IM modules (nbcio-boot-module-system/pom.xml:41-127).
Optional Microservice Support: Starter modules for job scheduling, distributed locks, and RabbitMQ (nbcio-boot-starter/pom.xml:18-22) are commented out by default, allowing teams to enable microservice capabilities when needed.
Dependency Direction: All business modules depend on the base-core module, ensuring consistent access to foundational utilities and configurations without creating circular dependencies.

Technology Stack Dependencies

The project leverages a mature technology stack centered on Spring Boot 2.3.5, with strategic integrations for workflow management, real-time communication, and enterprise integrations.

Technology	Version	Purpose	Selection Rationale
Spring Boot	2.3.5.RELEASE	Application framework	Stable LTS with proven production track record
Spring Cloud	Hoxton.SR8	Microservice support	Compatible with Spring Boot 2.3.x series
Spring Cloud Alibaba	2.2.3.RELEASE	Service discovery & config	Nacos integration for Chinese enterprise environments
MyBatis Plus	3.4.3.1	ORM framework	Enhanced MyBatis with pagination and code generation
Flowable	6.7.2	Workflow engine	BPMN 2.0 compliant, active community
Druid	1.1.22	Connection pool	SQL monitoring and wall filter protection
Dynamic Datasource	3.2.0	Multi-datasource	Runtime datasource switching without restart
Shiro	1.7.1	Security framework	Fine-grained permission control
Redisson	3.16.1	Distributed lock	Redis-based distributed coordination
Knife4j	2.0.9	API documentation	Enhanced Swagger UI with offline support

Core Framework Dependencies:

The parent POM establishes version consistency across all modules, defining Spring Boot 2.3.5 as the foundation along with Spring Cloud Hoxton and Alibaba Cloud 2.2.3 (pom.xml:8-21). This version alignment ensures compatibility across the entire technology stack.

Data Access Layer:

The base-core module integrates MyBatis Plus 3.4.3.1 for ORM operations, Druid 1.1.22 for connection pooling, and dynamic-datasource-spring-boot-starter 3.2.0 for multi-datasource support (nbcio-boot-base/nbcio-boot-base-core/pom.xml:93-112). This combination provides robust database access with monitoring capabilities.

Workflow Integration:

The flowable module independently integrates Flowable 6.7.2 with its Spring Boot starter (nbcio-boot-module-flowable/pom.xml:37-53), maintaining isolation from other business logic while providing BPMN 2.0 compliant workflow capabilities.

Core Configuration Infrastructure

The base-core module provides essential infrastructure configurations that all business modules inherit, establishing consistent behavior across the application.

Web MVC Configuration

The WebMvcConfiguration class implements WebMvcConfigurer to customize Spring MVC behavior with three primary responsibilities:

java
1// Key configuration areas from WebMvcConfiguration.java
2@Value("${jeecg.path.upload}")
3private String upLoadPath;
4@Value("${jeecg.path.webapp}")
5private String webAppPath;

Static Resource Handling: The configuration maps external directories for file uploads and web application resources, allowing dynamic content serving without redeployment (nbcio-boot-base/nbcio-boot-base-core/src/main/java/org/jeecg/config/WebMvcConfiguration.java:29-68).

Default View Controller: Root path requests redirect to doc.html, providing immediate access to Swagger API documentation (nbcio-boot-base/nbcio-boot-base-core/src/main/java/org/jeecg/config/WebMvcConfiguration.java:29-68).

CORS Filter: A conditional CORS filter enables cross-origin requests with credential support, configured through CorsFilterCondition for environment-specific activation.

HTTP Client Configuration

The RestTemplateConfig class provides a pre-configured RestTemplate bean with explicit timeout settings:

Read Timeout: 5000ms for response reading
Connect Timeout: 15000ms for connection establishment

These settings (nbcio-boot-base/nbcio-boot-base-core/src/main/java/org/jeecg/config/RestTemplateConfig.java:14-28) prevent indefinite blocking during external service calls, ensuring system responsiveness under network issues.

Static Configuration Management

The StaticConfig class centralizes external service credentials using @Value injection:

java
1@Value("${jeecg.oss.accessKey}")
2private String accessKeyId;
3@Value("${jeecg.oss.secretKey}")
4private String accessKeySecret;
5@Value("${spring.mail.username}")
6private String emailFrom;
7@Value("${jeecg.signatureSecret}")
8private String signatureSecret;

This approach (nbcio-boot-base/nbcio-boot-base-core/src/main/java/org/jeecg/config/StaticConfig.java:12-37) keeps sensitive configuration in property files rather than code, supporting environment-specific deployments.

Base Configuration Properties

The JeeccgBaseConfig class defines a simple safeMode flag that controls security-related behavior across the application:

java
1private Boolean safeMode = false;

This configuration (nbcio-boot-base/nbcio-boot-base-core/src/main/java/org/jeecg/config/JeeccgBaseConfig.java:12-25) provides a global switch for enabling stricter security validations in production environments.

Business Module Integration

The system module acts as the integration hub, combining all business modules into a cohesive application while maintaining their independence.

正在加载图表渲染器...

System Module Dependencies

The system module's POM file reveals its role as the integration point, declaring dependencies on:

nbcio-system-local-api: Local API interfaces for system services
jeewx-api 1.4.6: WeChat integration capabilities
jimureport-spring-boot-starter 1.4.0: JimuReport integration for reporting
nbcio-boot-module-demo: Demo examples showcasing framework features
nbcio-module-estar: Enterprise workflow integration
nbcio-boot-module-im: Instant messaging capabilities

This dependency structure (nbcio-boot-module-system/pom.xml:41-127) demonstrates the monolithic deployment approach where all modules run within a single JVM process.

IM Module Architecture

The IM module implements real-time communication using t-io WebSocket server:

xml
1<dependency>
2    <groupId>org.t-io</groupId>
3    <artifactId>tio-websocket-server</artifactId>
4    <version>3.7.0.v20201010-RELEASE</version>
5</dependency>

Additional dependencies include Jedis 4.1.1 for Redis operations and Spring Data Redis 2.6.1 for session management (nbcio-boot-module-im/pom.xml:24-53). This combination enables distributed session handling across multiple application instances.

Estar Module Integration

The estar module combines Flowable workflow capabilities with DingTalk SDK integration:

xml
1<dependency>
2    <groupId>com.aliyun</groupId>
3    <artifactId>dingtalk</artifactId>
4    <version>1.2.15</version>
5</dependency>

The module depends on both the base-core module and the flowable module (nbcio-module-estar/pom.xml:23-54), enabling enterprise workflow scenarios that integrate with DingTalk's organizational structure.

Data Flow Request Processing

Understanding the request flow from entry point to data persistence reveals the architectural patterns employed throughout the system.

正在加载图表渲染器...

Request Processing Stages:

Security Filtering: All requests pass through Shiro's security filter, validating JWT tokens and checking permissions against configured realms.
Controller Routing: The WebMvcConfiguration routes requests to appropriate controllers, with static resources served directly from configured paths (nbcio-boot-base/nbcio-boot-base-core/src/main/java/org/jeecg/config/WebMvcConfiguration.java:29-68).
Service Layer Processing: Business logic executes within transactional boundaries, utilizing MyBatis Plus for database operations with automatic pagination support.
Caching Strategy: Redis-based caching reduces database load, with Redisson providing distributed lock capabilities for cache coherence.
Response Serialization: JSON responses leverage Jackson with configured serializers for consistent date formatting and null handling.

Build Deployment Profiles

The project supports multi-environment deployment through Maven profiles, enabling environment-specific configuration without code changes.

Profile Configuration

Three profiles are defined in the parent POM:

Profile	Activation	Nacos Address	Use Case
dev	Default (activeByDefault)	127.0.0.1:8848	Local development
test	Manual (-Ptest)	127.0.0.1:8848	Integration testing
prod	Manual (-Pprod)	127.0.0.1:8848	Production deployment

Each profile configures:

profile.name: Environment identifier
prefix.name: Configuration file prefix (jeecg)
config.server-addr: Nacos configuration center address
config.namespace: Namespace ID for environment isolation
config.group: Configuration group name
discovery.server-addr: Nacos service discovery address

These settings (pom.xml:342-401) enable centralized configuration management through Nacos, supporting dynamic configuration updates without application restart.

Build Plugin Configuration

The build section configures essential plugins:

xml
1<plugin>
2    <groupId>org.apache.maven.plugins</groupId>
3    <artifactId>maven-compiler-plugin</artifactId>
4    <configuration>
5        <source>1.8</source>
6        <target>1.8</target>
7        <encoding>UTF-8</encoding>
8    </configuration>
9</plugin>

Key build configurations (pom.xml:287-340) include:

maven-compiler-plugin: Java 8 compilation with UTF-8 encoding
maven-surefire-plugin: Test skipping for faster builds
maven-resources-plugin: Font file exclusion from filtering to prevent binary corruption

Spring Boot Packaging

The system module configures the Spring Boot Maven plugin for executable JAR creation:

xml
1<plugin>
2    <groupId>org.springframework.boot</groupId>
3    <artifactId>spring-boot-maven-plugin</artifactId>
4    <configuration>
5        <skip>false</skip>
6        <fork>true</fork>
7        <includeSystemScope>true</includeSystemScope>
8    </configuration>
9</plugin>

The includeSystemScope setting (nbcio-boot-module-system/pom.xml:129-142) ensures system-scoped dependencies (DingTalk SDK JARs) are included in the final package.

Module Dependency Graph

The following diagram illustrates the dependency relationships between modules, showing how the architecture maintains clear separation while enabling code reuse.

正在加载图表渲染器...

Dependency Principles:

Unidirectional Dependencies: All dependencies flow downward from business modules to foundation modules, preventing circular references.
Core Module as Foundation: The base-core module serves as the common foundation, providing configuration, security, and data access capabilities to all business modules.
Business Module Independence: Business modules (flowable, im, estar, demo) can be developed and tested independently, only requiring the base-core module.
Optional Microservice Capabilities: Starter modules remain optional, commented out in the parent POM by default, allowing teams to adopt microservice patterns incrementally.

Key Design Decisions Trade-offs

Monolithic-First Architecture

Decision: The project defaults to a monolithic deployment with microservice capabilities commented out.

Rationale: This approach simplifies initial development and deployment while preserving the option to decompose into microservices. The module boundaries are already established, making future extraction straightforward.

Trade-off: Teams requiring immediate microservice deployment must uncomment the starter modules and configure service discovery, adding initial complexity.

Multi-Database Support

Decision: Integration of dynamic-datasource-spring-boot-starter enables runtime datasource switching.

Rationale: Enterprise applications often require separation of concerns across multiple databases (e.g., read replicas, tenant isolation, legacy system integration).

Trade-off: This flexibility introduces complexity in transaction management and requires careful configuration to prevent connection pool exhaustion.

Flowable Integration Strategy

Decision: Flowable is integrated as a separate module rather than embedding workflow logic within business modules.

Rationale: This separation allows workflow capabilities to evolve independently and enables reuse across multiple business contexts (demo, estar modules both leverage flowable).

Trade-off: Changes to workflow APIs require coordination across dependent modules, though this is mitigated by the base-api module's interface definitions.

Security Framework Selection

Decision: Apache Shiro is chosen over Spring Security for authentication and authorization.

Rationale: Shiro provides a more intuitive permission model for Chinese enterprise applications, with simpler integration for legacy systems.

Trade-off: Spring Security's deeper integration with Spring ecosystem features (OAuth2, SAML) requires additional configuration.

Configuration Management Approach

Decision: Nacos serves as the configuration center, with environment-specific profiles.

Rationale: Nacos provides both configuration management and service discovery in a single solution, reducing operational complexity.

Trade-off: This creates a dependency on Nacos availability; the configuration fallback mechanism requires verification for production deployments.

WebSocket Implementation

Decision: t-io WebSocket server is used instead of Spring's native WebSocket support.

Rationale: t-io provides superior performance for high-concurrency scenarios and includes built-in cluster support through Redis integration.

Trade-off: This introduces a non-Spring framework dependency, requiring team familiarity with t-io's programming model.

Build Configuration

Decision: Maven profiles manage environment-specific configuration rather than Spring profiles alone.

Rationale: Maven profiles enable build-time configuration injection, ensuring environment-specific properties are baked into the artifact.

Trade-off: This requires rebuilding artifacts for each environment, though the Nacos integration mitigates this by externalizing runtime configuration.

Dependency Version Management

Decision: All version numbers are centralized in the parent POM's properties section.

Rationale: Centralized version management ensures consistency across modules and simplifies security updates (e.g., Log4j2 version bump to 2.15.0).

Trade-off: Modules cannot easily override versions for specific use cases without affecting the entire project.