- The Development Studio does not restrict Module Creation to only a Single Module, however, I have not found anywhere that indicates if we should just create one or if we should create several. Is there a recommendation on this?
- If multiple modules are expected/allowed, are there any guidelines or recommendations that should be considered when establishing more than one?
- Modules should alway have a comment header at the top to clearly explain the logic of the rule. The value of this will sink in a year after you create the rule, need to make a change and have no clue what/why you did.
- Modules names should reflect the logic in the modules so others can reasonably guess the purpose of the module. (i.e. "RequireUnderwriter", "AddInvoiceNumber")
- That being said, if you have several very short CORs, there is no reason you can't combine them into a single module.
- Modules should alway have a comment header at the top to clearly explain the logic of the rule. The value of this will sink in a year after you create the rule, need to make a change and have no clue what/why you did. (This is not a duplicate.)
If you have common code that is used in multiple modules, you can create a module (maybe called "CommonDefs") to hold these so you only have to edit a single module.
I was never sure if the recommendation was to create a Module per Field/Rule or if we were to build one overall Super Module that housed all the rules being applied. I assume there may be some type of resource tradeoff based on the objects being referenced unless this is consolidated when the individual modules are compiled into the orders.
Anyway, Thank you again for your response and the information provided.