If you’re building backend systems in Java, you’re already orchestrating business logic.
You just don’t call it that.
Every time you write something like:
if (isValid(order)) {
var enriched = enrich(order);
var result = process(enriched);
}
you are defining a flow.
It works… at first.
But as the system grows, this turns into:
chained validations
multiple service calls
scattered error handling
mutable state passed around
logic that becomes fragile to change
And eventually:
your business logic becomes hard to follow, harder to maintain, and risky to evolve
The real problem
Java isn’t the issue.
The problem is how we end up structuring orchestration:
Map<String, Object> context = new HashMap<>();
context.put("order", order);
if (validate(context)) {
enrich(context);
process(context);
}
This leads to:
no type guarantees
implicit coupling between steps
runtime surprises
painful refactoring
What if flows were explicit?
Instead of manually wiring everything, what if you could describe the flow itself?
flow(order)
.then(validate)
.then(enrich)
.then(process);
That’s the idea behind FlowForge.
What is FlowForge?
FlowForge is an open-source library for Java that lets you define business logic as typed, composable flows.
Each step has clear input/output types
Steps connect automatically
The flow is validated before execution
Everything runs inside your application
No shared context.
No glue code.
No guessing what comes next.
What does it actually change?
- Types instead of mutable context
Each step declares exactly what it needs and what it returns.
No more:
Map
- Composition instead of control flow
You stop managing execution with if/else
and start describing the pipeline itself.
- Errors move left
Instead of discovering issues in production:
flows are validated upfront
- Less code, clearer intent
No manual data passing.
No adaptation layers.
No orchestration boilerplate.
What FlowForge is NOT
Let’s be explicit.
FlowForge is not:
a workflow engine
a BPM tool
a visual designer
an external runtime
You don’t need:
servers
orchestration engines
additional infrastructure
Unlike platforms like Camunda or Temporal:
FlowForge runs inside your codebase, not outside of it
Where does it fit?
FlowForge works the same whether you use:
plain Java
Spring
Spring Boot
Because it doesn’t depend on external systems.
It simply improves how you structure logic you already write.
When should you use it?
Anytime your backend logic involves multiple steps:
request processing
validation pipelines
service orchestration
data enrichment
business flows inside services
If your code has grown beyond simple method calls, you’re already in this space.
Open Source
FlowForge is fully open source.
no lock-in
transparent design
open to contributions
Try it
Source code on GitHub (royada-labs/flowforge)
Examples: https://github.com/royada-labs/flowforge-samples
Documentation: https://royada-labs.github.io/flowforge/
Available on Maven Central
Final thought
FlowForge doesn’t introduce a new layer.
It simplifies one that already exists.
the way you orchestrate business logic in Java
No engines.
No infrastructure.
No magic.
Just clearer, safer, more composable code.
Top comments (0)