SSM + UniApp Pharmacy Management & Sales Mini-Program: Three-Role Permission System with Real-Time Inventory Synchronization

Project Overview

This is a pharmacy management and sales system built with an SSM backend architecture and UniApp frontend framework. It adopts a front-end/back-end separation design, covering the complete business workflow from drug procurement and inventory management to online customer purchases. The system implements three role-based permissions—regular users, sales staff, and administrators—making it a typical digital management solution for small to medium-sized pharmacies.

For students learning Java Web development or preparing graduation projects, this project covers core functional modules including permission management, inventory control, and e-commerce shopping workflows, offering significant learning and reference value.

Technical Architecture Analysis

Backend: SSM Framework Service Layer

The project backend uses the classic SSM (Spring + SpringMVC + MyBatis) architecture rather than the more popular SpringBoot. While SSM requires more configuration effort, it's extremely helpful for understanding the underlying principles of the Spring ecosystem. The SSM architecture requires developers to manually configure components like DispatcherServlet, data sources, and transaction managers—a process that helps beginners gain deeper insight into how frameworks work.

From a foundational perspective, the three SSM frameworks each serve distinct roles while working closely together: Spring acts as the core container responsible for object creation and dependency injection (IoC/DI), managing Bean lifecycles through XML configuration or annotations. Developers don't need to manually instantiate objects—the container uniformly manages dependencies between objects. SpringMVC serves as the presentation layer framework, with DispatcherServlet as its core front controller. It receives all HTTP requests, finds the corresponding Controller method through HandlerMapping, and returns responses via ViewResolver. The entire request processing flow follows a strict chain of responsibility pattern. MyBatis serves as the persistence layer framework, binding Java objects to SQL statements through XML mapping files or annotations. Compared to Hibernate's fully automated ORM, MyBatis provides more flexible SQL control, allowing developers to write optimized SQL for complex queries. When the three work together, Spring integrates the other two frameworks and ensures data operation atomicity through declarative transaction management (the @Transactional annotation).

Frontend: UniApp Cross-Platform Mini-Program Development

The mini-program is developed using the UniApp framework, allowing code to be written once and compiled for multiple platforms including WeChat Mini Programs, H5, and even native Apps. UniApp is based on Vue.js syntax, has a low learning curve, and is easy for frontend developers to pick up.

UniApp's cross-platform capability stems from its conditional compilation and runtime adaptation mechanisms. During compilation, UniApp converts Vue single-file components (.vue) into native code for each platform—generating wxml/wxss/js files for WeChat Mini Programs, standard HTML/CSS/JS for H5, and rendering native components through weex or nvue for Apps. UniApp includes a built-in uni-app runtime library that smooths over API differences across platforms, allowing developers to call unified APIs like uni.request() to handle multi-platform network requests. Its component system is compatible with mini-program component specifications while supporting Vue's reactive data binding and component communication mechanisms (such as props, events, and Vuex state management), enabling developers to build cross-platform applications using familiar Vue development patterns.

Advantages of Front-End/Back-End Separation Architecture

The entire project adopts a front-end/back-end separation design pattern, with the admin management system and mini-program communicating with the backend through RESTful APIs. RESTful API is an interface design style based on the HTTP protocol, with core principles including: using URLs to represent resources (e.g., /api/drugs/123 represents the drug with ID 123), HTTP methods to represent operations (GET for queries, POST for creation, PUT for updates, DELETE for deletion), and HTTP status codes to represent results (200 success, 404 not found, 500 server error). The front and back ends exchange data in JSON format, with the backend solely responsible for providing data interfaces without rendering pages.

The advantages of this architecture include:

• Front-end and back-end can be developed in parallel, improving team collaboration efficiency
• Strong interface reusability—a single API can serve multiple frontends (web admin panel, mini-program, mobile app, etc.)
• Flexible deployment—front-end and back-end can be deployed and scaled independently

Detailed Three-Role Permission Design

The system's three-role permission design is essentially a simplified implementation of the RBAC (Role-Based Access Control) model. The core idea of RBAC is to assign permissions to roles, then assign roles to users, avoiding the complexity of configuring permissions individually for each user. In technical implementation, the backend typically uses interceptors or filters to perform permission verification before requests reach the Controller, checking whether the current logged-in user's role has access to the target interface. More mature solutions use security frameworks like Spring Security or Shiro, supporting fine-grained method-level permission control and dynamic permission configuration.

Administrator: Highest System Privileges

Administrators have the highest system privileges and are primarily responsible for:

• Drug Category Management: Creating and modifying drug categories, including category names and icons
• Data Statistics: Viewing business data through visual reports such as pie charts
• Order Review Monitoring: Monitoring user feedback and order statuses
• User & Sales Staff Management: Managing account information for all roles in the system

Sales Staff: Core Daily Operations Role

Sales staff are the core role for daily operations, with permissions including:

• Drug Data Management: Maintaining drug names, shelf life, efficacy descriptions, detailed introductions, etc.
• Stock-In Operations: Selecting drugs and entering stock-in quantities to complete procurement
• Stock-Out Operations: Processing sales stock-out workflows
• Order Management: Viewing and updating the status of customer purchase orders

Regular Users: Complete E-Commerce Shopping Experience

The user-facing side provides a complete e-commerce shopping experience:

• Browse drug listings and categories
• View drug details and user reviews
• Add items to cart and place orders
• Fill in shipping information and select payment methods
• Confirm receipt and leave reviews
• Modify personal information and reset passwords

Core Feature Highlights

Real-Time Inventory Synchronization Mechanism

The system implements real-time inventory change control, which is a key technical highlight of the project:

1. Stock-In Increases Inventory: When sales staff perform stock-in operations, the corresponding drug's inventory quantity automatically increases
2. Purchases Decrease Inventory: After a user successfully places an order, inventory is automatically deducted
3. Zero-Stock Interception: When a drug's inventory reaches zero, the system prevents users from purchasing, and the frontend grays out the purchase button

This design prevents overselling, which is critically important in real business scenarios. However, it's worth noting that in high-concurrency scenarios, simple inventory deduction may have thread safety issues. In production environments, optimistic locking or distributed locks are typically needed to ensure data consistency.

From a technical implementation perspective, common inventory concurrency control solutions include: pessimistic locking (SELECT ... FOR UPDATE) which locks data rows during queries—suitable for write-heavy scenarios but with poor performance; optimistic locking through a version number mechanism that checks whether the version has changed during updates—suitable for read-heavy scenarios; and distributed locks (such as Redis's SETNX command or the Redisson framework) for distributed deployment environments. For a pharmacy system of this small-to-medium scale, database-level optimistic locking (UPDATE stock SET quantity=quantity-1 WHERE id=? AND quantity>0) is usually sufficient. The success of the deduction is determined by the number of affected rows—if it returns 0, it indicates insufficient stock, and the purchase request is rejected.

Complete E-Commerce Shopping Loop

The system implements a standard e-commerce shopping loop:

Browse → Add to Cart → Place Order → Pay → Ship → Receive → Review

Behind this workflow is a rigorous order state machine (FSM, Finite State Machine) model. Each order goes through multiple states during its lifecycle: Pending Payment → Paid → Pending Shipment → Shipped → Received → Reviewed, along with possible exception states like Cancelled or Refunded. Transitions between states are triggered by specific events (such as user payment or merchant shipment), and transition rules are strictly defined—for example, only orders in "Paid" status can be marked as "Shipped." In code implementation, enum classes are typically used to define state constants, and the State Pattern or Strategy Pattern manages state transition logic, ensuring illegal state transitions are rejected by the system to maintain business data consistency.

Each step has corresponding state transitions. Backend sales staff can modify order statuses (such as marking as shipped or received), and users can review drugs after confirming receipt. Review content is displayed on the drug detail page for other users' reference.

Data Visualization & Statistical Reports

The admin backend integrates data statistics functionality, using chart components like pie charts to display business data, helping pharmacy managers intuitively understand key metrics such as sales performance and user distribution. Frontend charts are typically implemented using visualization libraries like ECharts or uCharts, fetching aggregated data through backend APIs and rendering interactive charts in the browser, supporting data drill-down and dynamic refresh.

Learning & Advanced Recommendations

For developers looking to study or reference this project, here are some recommended areas to focus on:

1. Understand SSM Configuration Principles: Focus on Spring's IoC container configuration, MyBatis Mapper mappings, and SpringMVC's request dispatching mechanism. Review the applicationContext.xml and spring-mvc.xml configuration files line by line to understand each Bean's role and dependencies
2. Study Permission Control Implementation: Analyze how the three roles' permissions are intercepted and authenticated on the backend. Pay attention to how interceptors retrieve user Session or Token information and how interface access permissions are determined based on roles
3. Learn Inventory Management Logic: Understand transaction control for inventory changes, consider optimization strategies for concurrent scenarios, and try using tools like JMeter to simulate concurrent requests to test inventory deduction correctness
4. Master UniApp Development Patterns: Familiarize yourself with component-based development and mini-program lifecycles (onLoad, onShow, onReady, etc.), and understand page stack management and data caching strategies

If you have the capacity, try upgrading the SSM architecture to SpringBoot to experience the differences in development efficiency. SpringBoot simplifies what would otherwise require dozens of lines of XML configuration into just a few annotations through its Auto-Configuration and Starter dependency mechanisms. This is very helpful for understanding the evolution of Java Web technology from "configuration-driven" to "convention over configuration."

Summary

This pharmacy management and sales system is feature-complete with clear business logic, covering multiple practical modules including permission management, inventory control, e-commerce workflows, and data statistics. As a Java learning project or graduation design reference, it provides an excellent example of building a complete business system from scratch. For real pharmacy application scenarios, additional features such as prescription drug management (requiring integration with hospital prescription systems for electronic prescription verification), drug expiration date alerts (using scheduled tasks to scan soon-to-expire drugs and push notifications), and membership points systems could be added to further enhance the system and bring it closer to real pharmacy digital operation needs.