Stop Orchestrating Business Logic with if/else — A Better Way in Java

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?

1. Types instead of mutable context

Each step declares exactly what it needs and what it returns.

No more:

Map

1. Composition instead of control flow

You stop managing execution with if/else

and start describing the pipeline itself.

1. Errors move left

Instead of discovering issues in production:

flows are validated upfront

1. 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.