Epic #7
openRBAC module with user management
0%
Description
TO DO:
What is a Modular Monolith? You will build one Spring Boot application, but
inside the code, you will strictly separate modules (Users, Orders, Inventory,
Loyalty) into different packages. They will communicate through interfaces, NOT
direct database joins.
Pros: Fast to develop, easy to deploy, simple transaction management (ACID),
much cheaper hosting.
Future-proof: Because the code is modular, if the "Order" module gets too
heavy in year 2, you can easily cut it out into its own Microservice.
Tech Stack:
Framework: Java Spring Boot 3.x
Database: PostgreSQL (Best for relational POS data, highly scalable)
Security: Spring Security + JWT (JSON Web Tokens for Web/Mobile/POS auth)
ORM: Spring Data JPA (Hibernate)
Part 2: Designing the User Module
Since you have a multi-channel system (POS Terminal, Mobile App, Website), your
User Module needs to handle two main types of users: Staff (Admins, Cashiers,
Managers) and Customers (Web/Mobile buyers).
To keep it 100% dynamic (no hardcoding), we will use a dynamic Role-Based Access
Control (RBAC) system in the database.
A. users Table (The core table for everyone)
id (UUID, Primary Key)
email (String, Unique)
password_hash (String)
phone_number (String, Unique)
first_name (String)
last_name (String)
is_active (Boolean, default true)
user_type (String - "STAFF" or "CUSTOMER")
created_at / updated_at (Timestamps)
B. roles Table (Dynamic roles, no hardcoded enums)
id (UUID, Primary Key)
role_name (String, e.g., "Super Admin", "Cashier", "Customer")
description (String)
C. permissions Table (Dynamic permissions)
id (UUID, Primary Key)
permission_name (String, e.g., "CREATE_ORDER", "VIEW_INVENTORY",
"REFUND_ORDER")
D. Mapping Tables (For Dynamic Assignment)
user_roles: user_id | role_id (A user can have multiple roles)
role_permissions: role_id | permission_id (Admins can change what a
"Cashier" is allowed to do via the UI).
E. customer_profiles Table (Specific to Web/Mobile users)
id (UUID, Primary Key)
user_id (Foreign Key -> users.id)
loyalty_points (Integer, default 0)
default_shipping_address (String/JSON)
F. staff_profiles Table (Specific to POS terminal users)
id (UUID, Primary Key)
user_id (Foreign Key -> users.id)
store_id (Foreign Key to future Store module)
pos_pin (String - Hashed 4-digit pin for fast POS login)
REST API Endpoints for User Module
Your mobile app, website, and POS front-end will call these APIs.
Authentication:
POST /api/v1/auth/login (Takes email/password, returns JWT token)
POST /api/v1/auth/pos-login (Takes POS PIN + Store ID for fast cashier
switching)
POST /api/v1/auth/register (For new mobile/web customers)
User Management (Admin Only):
POST /api/v1/users/staff (Create a new cashier/manager)
GET /api/v1/users (List all users with filters)
PUT /api/v1/users/{id}/status (Activate/Deactivate user)
Role & Permission Management (Dynamic):
POST /api/v1/roles (Create a new custom role, e.g., "Weekend Cashier")
POST /api/v1/roles/{roleId}/permissions (Assign permissions to a role)
Customer (Mobile/Web calls):
GET /api/v1/users/me (Get own profile & loyalty points)
PUT /api/v1/users/me (Update own details)
Spring Boot Directory Structure (Modular Monolith)
This is how your Java project should look for this module:
com.pos.system
│
├── core/ # Global configs (Security, JWT, Error Handling)
│
├── modules/
│ ├── user/ # <--- WE ARE HERE
│ │ ├── controllers/ # AuthController, UserController, RoleController
│ │ ├── services/ # UserService, AuthService, RoleService
│ │ ├── repositories/ # UserRepository, RoleRepository (Spring Data JPA)
│ │ ├── entities/ # User, Role, Permission, CustomerProfile
│ │ ├── dtos/ # UserRegistrationRequest, JwtResponse, etc.
│ │ └── security/ # Custom UserDetailsService for Spring Security
│ │
│ ├── inventory/ # (Next step...)
│ ├── orders/ # (Future step...)
│ └── loyalty/ # (Future step...)
Why this design fits your vision:
Fully Dynamic: If you want to hire a "Junior Cashier" who can only create
orders but cannot process refunds, the Super Admin just creates a new Role
in the POS frontend, assigns specific permissions from the DB, and attaches
it to the user. No code deployment needed.
Omnichannel Ready: The exact same user account can log into the Mobile App
(as a customer) or the POS System (as staff) based on their user_type and
roles.
Performance: Staff can log in quickly using a pos_pin, which is a standard
requirement for fast-paced POS environments.