Design and Implementation of a Generic Data‑Change Tracking and Dynamic Display System

1. Background

In everyday business development, it is common to record operation logs for key business functions, capturing who performed what action and the before‑and‑after data. When business logic is split into multiple projects, challenges arise in decoupling log recording from business code, simplifying log integration, and comparing field changes.

2. Expected Goals

Design and implement a generic data‑change tracking and dynamic display (object description) solution that allows developers to mark data for tracking via simple annotations. The system automatically captures add, modify, and delete operations, records each step of data changes, and provides a dynamic interface for clear, intuitive presentation of change details.

Key objectives include providing a universal data‑structure interface without extra front‑end field definitions and enabling low‑cost, rapid recording of every model field’s before‑and‑after values.

3. Technical Selection and Comparison

3.1 Business Code Nesting – Directly inserting logs in business code increases complexity and is not generic.

3.2 Canal – Alibaba’s open‑source binlog‑based incremental data subscription component. It captures raw database changes (insert, update, delete) but does not handle multi‑table business relationships, requiring custom assembly of data.

3.3 Triggers – Increase DB complexity and maintenance cost; potential performance issues, thus not considered.

3.4 AOP – Aspect‑Oriented Programming separates cross‑cutting concerns (e.g., logging) from business logic, generating dynamic proxies and weaving aspects; part of the implementation relies on AOP.

4. System Design and Implementation

The solution is built on Annotation + AOP + SpringEL + Swagger, using AOP to intercept controller methods annotated with a custom @TrackingPoint. SpringEL evaluates expressions to fetch pre‑ and post‑execution data via the service’s getById method. Swagger scans @ApiModel‑annotated models to cache definitions. MongoDB stores the change logs.

4.1 Define Filter (TrackingAccessFilter)

Initializes request context and parses request information.

4.2 Define Annotation (@TrackingPoint)

Specifies operation type, module alias, title, login requirement, model ID, tracker bean, pre‑event and post‑event expressions.

4.3 Define Tracker Interface

Business services implement this to provide getById, listByIds, etc., enabling snapshot comparison and description generation.

4.4 Define AccessUserService

Callback interface for obtaining current user information when login=true.

4.5 Define TrackingPointAspect

Intercepts annotated controller methods, parses annotations, executes SpringEL to obtain data snapshots, synchronously captures pre‑change data, and asynchronously processes post‑change events.

4.6 Log Storage

Uses MongoDB as the default NoSQL store for flexible field changes; custom log handlers can be provided by implementing AccessLogPersist.

4.7 Define Generic Interface Rules

Returns oldObject, newObject, objectDescription, user, module, title, and type to enable dynamic front‑end rendering of change details.

5. Practical Case

Demonstrates a user‑information update scenario with sequence diagrams, Maven dependencies, implementation of user‑info callback, business interface callbacks, and log insertion. Sample JSON payloads for updating a User and a Task are shown:

{
  "age": 32,
  "id": 1,
  "username": "姜强"
}
{
  "contractName": "jturbo",
  "id": 1,
  "name": "任务名称2"
}

Front‑end displays change details for both user and task modules using the generic interface, optionally leveraging JSONDiff for highlighting differences.

6. Summary and Outlook

The approach achieves decoupled, reusable data‑change tracking across business systems via annotations and AOP, improving maintainability and auditability. Future work includes adding one‑click rollback functionality.