We have a "workflow orchestration" system at work.

It works something like this:

You configure what to run (in a database table), such as:

NameOfStepATHingToRun ="weather_data"
RunStepB? = No
RunStepC? = Yes
StepCArguments = Canada,USA

(this goes on with maybe 20 total columns)

Then your configuration is run through a few large functions, with lots of if/else statements

The problem for me is that if I want to change something, like adding a step or having a different way to run a step, then that change affects every workflow - and there ain't a lot of testing going on

It certainly feels like an anti-pattern/design smell to me, but I can't find a name for it

  • 1
    What is it about this scheme that you dislike sufficiently that you think it isn't just a different way of doing things than you'd do it yourself but instead is actually bad, in fact, bad enough that the community would think it was an 'anti-pattern'? – davidbak Feb 22 at 16:19
  • 1
    There is a refactoring called replace conditional with polymorphism. However that has nothing to do with orchestration. It only applies when the conditional value is known well ahead of the executing code. – candied_orange Feb 22 at 16:23
  • @davidbak the problem arises if i want to run step D (which doesn't exist), or run C before B – Neil McGuigan Feb 22 at 16:29
  • From what you've written, it looks like your main concern is that the whole logic is placed in a couple of very large functions, and that the code is pretty tangled up, with different concerns not clearly separated or explicitly represented. In other words, it's hard to make localized changes without causing ripple effects or having to understand seemingly unrelated parts of the code. Is that about right (is it a good summary of your question)? – Filip Milovanović Feb 22 at 16:56
  • 2
    IMO - and Jon Raynor is right - what you've got here is an ad hoc, extended-(and-'designed')-as-needed) approach to something which, if all the requirements had been known in advance, would have been done with a more general tool. Possibly including one that was off-the-shelf. If it is causing you sufficient grief now, or can reasonably be expected to cause you sufficient grief in the predictable short-to-medium term, it might be economically feasible to replace it with a proper decision table. (Rules engine might be overkill.) The timing of that is a cost-benefit analysis for you. – davidbak Feb 22 at 17:16

It is the start of a rules engine. Usually, there is a defined line between the code and the configuration. When that line blurs, or when the application needs user input on how to execute logic with the user defining data and potential logic, then you have a rules engine. This user data and rules make the application perform in certain ways. Granted in your case it's pretty rudimentary with if/else but it's still the start of a rules engine.

In your case, there is some data, like "Weather_data". This is data telling what to run. There is also some logic, like "Run_StepB".

I could take that entire configuration and codify it with a method like: RunWeatherForCanadaNoStepB()

If you going to continue to go down the route of having users decide how to run things, then take the rudimentary if/else logic and write a more robust engine to take the input and run it.

  • 2
    It could also be a workflow engine. – Robert Harvey Feb 22 at 22:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.