Closed pervrosen closed 2 years ago
Interesting. How would the rule determine if there is a single happy path or not?
Ends not part of happy path should be modeled as business exceptions, not as regular end points, (business outcomes). And a function that "must" have many end points due to choices along the way should instead model the choice as information then used to choose yet another happy path process. One could perhaps also use DMN to encapsulate. What I want to see is for each and every process/function a clear purpose, not "it fixes it all"-process.
I guess what would really help us if you could sketch do's and dont's along the lines of our existing documentation. What is the rationale? What are do and don't examples?
Without that input you're request is not actionable for us.
Lets just close this. Sorry for wasting your time.
Sorry for wasting your time.
You do not waste our time. We just have to make sure that we understand your request, and we need your help to do that.
What you describe is something that I think makes a lot of sense in terms of modeling good practices. But how does it look in practice? What do you refer to as happy ending and bad ending? All questions need to be answered in order for us to understand if we can
(1) have a reasonable pattern at hand (2) can actually programmaticaly detect that pattern
Hope that makes sense.
Closing due to missing input.
The rule should detect the following modeling patterns
A process should have a "happy path". Only have one starting point and one "happy path"-end point. All other outcomes should be expected to be exceptions. If one need "many" outcomes, then one should model the process as capturing and/or processing the many outcomes in the process.
How does the rule improve the BPMN diagram?
The process becomes clear and not cluttered. Readability is improved as well as automation.
Rule Details
warning
What alternatives did you consider?
Spaghetti process/code is always an option.