One interesting perspective I often hear about workflows is how approaching
them with configuration is better than with code, or the opposite, depending
on who you're talking to.
Many established products in the workflow orchestration space claim it's
easier to write workflows as code. The biggest argument in favor of this is
that complexity is better addressed in code compared to a configuration or
DSL. This comes with the assumption that workflows will be where the logic
lives.
My personal take is that this anticipated complexity doesn't really exist.
The moment your code leaves the boundary of a single method, you're already
orchestrating outside of your code. And you end up building a deeply
coupled, hard-to-maintain system when the orchestration leaves your library
boundary to another app or service.
Code as Building Blocks
A building-blocks code model, interconnected only via orchestration, gives
you cleaner, more testable, and maintainable code, and lets you retain a
simpler, maintainable architecture. Remember: you're still writing code —
you're just wiring things up using orchestration.
This is evident in how some of us use event-driven choreography. The entire
idea is to decouple and run services that aren't aware of each other. The
events being routed from one place to another don't have complexity that
can be resolved with code.
However, the challenge with choreography is the lack of visibility into how
things map. This is where the power of orchestration comes through.
Code vs Configuration
The topic of this debate is moot, because it's really your code that's
being orchestrated. It would make less sense to orchestrate within code.
Instead, the code you write should be orchestrated to create the flows that
meet your goals — while keeping things cleanly decoupled, unmeshed.
What are your thoughts on this? Is it time to unmesh your workflow
complexity from code?
Top comments (0)