I dont think that I will use the naming convention has been proposed by Scott Colestock ... the reason is he is treating shapes and in the orchestration flow as variables while they are not !!! ... shapes should be descriptive as much as we can for the eye to see ... because you will only see the flow in two places : in design time ... and in debugging using HAT ... there for I dont wanna start translating these variables to its business equivalents meanings ... for example why would I name a decide shape "Decide_ApprovalRequired" while I can name it "Is Approval Required" ... its business descriptions not a developer descriptions eventually !!!!
1 Comments:
I dont think that I will use the naming convention has been proposed by Scott Colestock ... the reason is he is treating shapes and in the orchestration flow as variables while they are not !!! ... shapes should be descriptive as much as we can for the eye to see ... because you will only see the flow in two places : in design time ... and in debugging using HAT ... there for I dont wanna start translating these variables to its business equivalents meanings ... for example why would I name a decide shape "Decide_ApprovalRequired" while I can name it "Is Approval Required" ... its business descriptions not a developer descriptions eventually !!!!
Post a Comment
<< Home