Extracting Business System Knowledge through FSM‑X Visualization: A Practical Exploration

1 Background Introduction

1.1 Problem to Solve

System documentation is the primary means of preserving business system knowledge, but rapid iteration and staff turnover often lead to missing, inconsistent, or outdated documents, causing inefficiencies in development and collaboration.

These documentation issues directly affect development efficiency, product‑research collaboration, and overall quality, especially in teams with frequent personnel changes.

The diagram shows the ideal (green arrows) and reverse (red arrows) development processes caused by information gaps between roles.

1.2 Business System Background

Last year we refactored our system using Domain‑Driven Design (DDD). While DDD promotes a unified language and domain modeling, the final knowledge still resides in documentation.

We aim to find a generic method to automatically abstract and extract business knowledge from code, achieving a "code is documentation" effect.

2 Our Thinking

Raw code contains the needed knowledge but is unstructured; an intermediate abstraction layer is required to normalize and structure the code so that knowledge can be extracted.

2.1 What Is Business System Knowledge

Examples: product price must end with "8", or a product launch triggers an MQ notification. Two categories exist:

Pure Business Knowledge : pure business rules, independent of technical implementation.

System Knowledge : includes business rules and the technical implementation details needed to enforce them.

2.2 Where Knowledge Exists

Knowledge resides in various workflow control logic such as rule checks, conditional UI rendering, message listeners, or strategy‑pattern dispatches—essentially different implementations of IF‑ELSE logic.

2.3 How to Extract Business System Knowledge

Instead of DDD’s business‑centric modeling, we abstract workflow control into a "generalized design pattern" that captures IF‑ELSE variations, including classic patterns like Chain of Responsibility, Strategy, and the state machine (FSM) discussed later.

This abstraction makes the knowledge structured and extractable.

3 Exploratory Practice

Our system uses an extensible state machine framework called FSM‑X, which aligns with the abstraction idea and serves as a concrete implementation of the generalized design pattern.

3.1 FSM‑X

FSM‑X builds on a finite state machine and adds transaction messages, JOBs, etc. Core concepts include:

Mapping : a transition containing source state, target state, event, operation, and optionally JOB, TxMsg, or Chain.

Chain : links two Mappings so that the second executes automatically after the first.

JOB : asynchronous task triggered by a Mapping.

TxMsg : transaction message sent when a Mapping completes.

3.2 FSM‑X Visualization Implementation

The overall architecture is shown below:

FSMX Configuration Center centrally manages all configurations and provides retrieval APIs.

FSMX Client pulls configurations at service startup, converts state‑machine data into visual data, and reports it.

The Configuration Center caches visual data locally and renders it for external consumption.

Visualization nodes correspond to the core components:

Mapping

The example shows a "SUPPLY_PRODUCT" domain where the "quality‑check passed" event leads to an "on‑shelf" state, then to a "pre‑on‑shelf" state with 21 possible subsequent chains.

Chain

The red box highlights two possible chains after the "on‑shelf" operation, illustrating that further execution is controlled by custom generalized design patterns.

JOB

MSG

A more complete visual of the product on‑shelf workflow is shown below:

The diagram demonstrates the overall execution flow, but it remains a coarse‑grained framework; many knowledge pieces remain in unstructured code that cannot yet be abstracted.

4 Summary

We view FSM‑X as an abstraction of a class of workflow‑control logic, i.e., a concrete instance of the "generalized design pattern" discussed earlier. The visualization experiment shows that such patterns can capture and present state‑machine‑related business knowledge, though the completeness is limited because only one pattern was used.

Nevertheless, the results suggest that further abstraction of various workflow implementations could form a detailed code convention, enabling systematic extraction and preservation of business knowledge within that convention. Future work will continue to explore this direction.

About the Author

Wang Lun, Backend Development Engineer, ZheZhuan B2C Technology Department