Fluent Commerce Logo
Docs

Data Module Creation & Scaffolding

Use Case

Author:

Fluent Commerce

Changed on:

31 Mar 2026

Problem

Potential Problems:
  • No clean way to package non-code assets: Reference data, settings, and workflow fragments often live as loose files with no consistent structure, making them difficult to version, share, or deploy reliably.
  • Unnecessary complexity for configuration-only work: Using a full Java extension module to deploy data or configuration assets introduces build overhead, dependency management, and compilation steps that serve no purpose when there is no custom code involved.
  • Inconsistent deployment of reference data across environments: Without a module structure, reference data is often applied manually and inconsistently across environments, leading to configuration drift and hard-to-reproduce issues.
  • No versioning for configuration assets: Workflow fragments and settings deployed outside of a module have no formal version history, making it difficult to track what changed between environments or roll back to a previous state.
  • Friction in sharing reusable assets across teams: Configuration assets and workflow fragments that could be reused across projects often stay trapped in one implementation because there is no standard, shareable format to put them in.
You need to deploy reference data, workflow fragments, or configuration assets — no custom Java rules.

Solution Overview

Creating a data module begins with a single instruction that generates the full structure needed to package and deploy non-code assets. Unlike a standard extension module, this process skips everything related to Java: there are no build files, no source directories, and no test skeletons. The result is a lightweight, purpose-built structure designed specifically for carrying reference data, workflow fragments, settings, and other configuration assets.The scaffolded module includes the core metadata file that defines the module and its contents, an organised directory structure for the different types of assets it will hold, a configuration template, and a build script that packages everything into a deployable ZIP without requiring a compilation step.Once the structure is in place, assets can be added to the appropriate directories and the module can be built and deployed using the same process as any other module. This means data modules benefit from the same versioning, deployment verification, and environment targeting as code modules, without any of the Java overhead.The practical result is a consistent, repeatable way to manage and deploy configuration assets across environments, bringing the same discipline and traceability to reference data and workflow fragments that already exists for custom rule development.

Solution