Stop hardcoding business logic and start building maintainable workflow systems
The Problem Every Developer Faces
You get a simple requirement: “When someone submits an expense report, their manager needs to approve it, then accounting processes it.” Easy enough – a few database updates and some email notifications.
Three months later, the requirements have grown:
- Expenses over $500 need director approval too
- International expenses need additional tax review
- If a manager doesn’t respond in 48 hours, escalate to their manager
- Finance can reject and send back for corrections
- The whole thing needs to be auditable for compliance
Your simple approval logic has become a monster of nested if statements, state tracking, and edge case handling. Every change request breaks something else.
This is exactly why workflow engines and BPMN exist.
What BPMN Actually Solves
BPMN (Business Process Model and Notation) isn’t just flowcharts for business people. It’s a standardized way to model, execute, and manage complex business processes. More importantly, it separates your business logic from your application code.
Think about it this way: you wouldn’t hardcode SQL queries into your functions when you can use a database. Similarly, you shouldn’t hardcode workflow logic when you can use a workflow engine.
The Real Benefits
- Visual Process Management: Business stakeholders can understand and request changes to processes without diving into code.
- State Management: The engine tracks where each process instance is, what’s completed, what’s waiting, and what’s next.
- Built-in Patterns: Common workflow patterns like parallel execution, conditional routing, and error handling are built into the standard.
- Audit and Monitoring: Every step is automatically logged. You get complete visibility into process execution.
- Change Management: Updating a process means updating the BPMN model, not hunting through code for all the places workflow logic might be hidden.
Building with lib-bpmn-engine: Practical Experience
Building with Open-Source BPMN Engines: Practical Experience
After evaluating several workflow solutions, I chose to work with open-source BPMN libraries such as Camunda, Zeebe, and others in the Go ecosystem like nitram bpmn. Here’s what I learned and why this approach works.
Why This Library Works
Open-source BPMN engines are lightweight, flexible, and often have language-specific implementations. They integrate into existing applications without requiring a complete architectural overhaul.
The key insight: you don’t always need heavy enterprise BPM suites to solve workflow problems. What you really need is a reliable BPMN execution engine that plays well with your current stack and scales with your use case.
Setting Up the Foundation
The basic setup is straightforward – load a BPMN process definition and execute it. But the real power comes from connecting the workflow engine to your existing services and APIs.
You define service tasks in your BPMN that call out to your application logic. The workflow engine handles orchestration, state management, and routing. Your application code handles the actual business operations.
Service Tasks: Where Business Logic Lives
Service tasks are where your workflow connects to real work. Instead of embedding business logic in the workflow itself, you create service endpoints that the workflow calls.
For example, your “Send Approval Email” service task calls your email service. Your “Check Credit Limit” service task calls your finance API. The workflow orchestrates these calls but doesn’t implement the business logic itself.
This separation makes everything more maintainable. Business logic stays in your domain services. Workflow logic stays in the BPMN model.
The State Management Win
One of the biggest advantages is that you stop managing workflow state in your application code. The engine tracks process instances, knows which tasks are complete, which are waiting, and which are next.
Your application code becomes stateless workflow participants instead of stateful workflow managers. This is a huge simplification.
BPMN Elements That Matter in Practice
Gateways: Making Decisions
- Exclusive Gateways handle either/or routing based on conditions. Instead of if/else logic scattered through your code, you have visual decision points in your process model.
- Parallel Gateways handle concurrent execution. Tasks that can run in parallel (like sending notifications while updating databases) are explicitly modeled as parallel paths.
Timer Events: Handling Time
Timer events handle delays, timeouts, and scheduled tasks. Instead of building your own job scheduling system, you model time-based behavior directly in the process.
Need to escalate if approval takes too long? Add a timer boundary event to the approval task. Need to wait 24 hours before sending a reminder? Add an intermediate timer event.
User Tasks: Human Steps
User tasks represent work that people need to do. The engine manages task assignment, escalation, and completion tracking. Your application provides the user interface and handles task completion.
This separation means you can change assignment rules, escalation policies, and task forms without touching your core application logic.
Real-World Implementation Lessons
Keep Processes Focused
Don’t try to model your entire business in one BPMN process. Keep individual processes focused on specific workflows. If your process diagram doesn’t fit on one screen comfortably, it’s probably too complex.
Use sub-processes and call activities to break complex workflows into manageable pieces.
Plan for Process Changes
Business processes change constantly. Build versioning into your workflow system from the beginning. You need to handle running process instances on old versions while new instances use updated processes.
This is harder than it sounds. Plan for it early.
Error Handling is Critical
Real-world processes fail in unexpected ways. Services go down, external APIs timeout, and people make mistakes. Build error handling into your processes from the start.
Use boundary events for timeouts and errors. Design compensation logic for handling partial failures. Plan escalation paths for when things go wrong.
Monitoring and Observability
Workflow engines give you incredible visibility into business processes, but only if you instrument them properly. Log process events, track performance metrics, and build dashboards that show process health.
Business stakeholders love being able to see exactly where processes are stuck and how long things are taking. This visibility alone often justifies the workflow engine investment.
Common Mistakes to Avoid
1. Putting Too Much Logic in the Process
Keep your BPMN processes focused on orchestration, not implementation. Business logic belongs in your services, not in the workflow engine.
2. Ignoring Human Tasks
If your processes involve people, model that explicitly. Don’t try to work around the human elements – embrace them and build proper task management.
3. Poor Service Design
Design your service tasks as small, focused operations. Don’t create giant service tasks that do multiple things. This makes processes harder to understand and harder to change.
4. Skipping Error Scenarios
Happy path modeling is easy. The value comes from properly handling errors, timeouts, and edge cases. Spend time modeling what happens when things go wrong.
When BPMN Engines Make Sense
BPMN workflow engines aren’t the right solution for every problem. They make sense when:
- You have multi-step business processes involving multiple systems
- Business stakeholders need to understand and modify processes
- You need audit trails and process monitoring
- Processes involve human approval or review steps
- You have complex routing and decision logic
- Processes change frequently based on business requirements
They don’t make sense for simple CRUD operations, real-time data processing, or purely technical workflows that business people don’t care about.
The Bottom Line
Building workflow systems with proper BPMN engines changes how you think about business logic. Instead of embedding workflow concerns throughout your application code, you model processes explicitly and let the engine handle orchestration.
This separation makes your code cleaner, your processes more transparent, and changes easier to implement. Business stakeholders can see exactly how processes work and request changes with confidence.
The learning curve is real – BPMN has its own concepts and patterns. But once you understand the fundamentals, you’ll wonder how you ever built complex workflows without proper process modeling.
Start simple. Pick one workflow in your application that’s getting complex and model it in BPMN. You’ll quickly see the benefits and start finding other processes that would benefit from the same approach.
Most developers don’t know about workflow engines because they’re often marketed to business analysts and process managers. But they’re fundamentally developer tools for building better systems. Learn BPMN, understand workflow engines, and add them to your architecture toolkit.
