Organising rules in an application

Certified Associate Developer

Hi all

I want to hear some of the ways you guys organise the rules in an application in general or as a best practice.

For example, an application involving a couple of hundred rules would be hard to manage and understand for someone new to it. I've thought of organising rules in their dedicated folders by their feature/record type. I want to know what other patterns the community follows for better organising their rules?

  Discussion posts and replies are publicly visible

Parents
  • Since developers don't see rules in the application based on a folder hierarchy, I'm not sure this would provide much benefit.  We just push for standard, logical naming conventions with an application prefix, and generally I will create objects something like below.  One of the current applications I'm working on contains 525 objects with 190 of those being expression rules, with them named properly (with DESCRIPTIONS!) I don't have much issue finding what I need.  Typically as well, I'm working through an interface or process model which shows me which rule(s) it's calling in the areas I'm updating anyway, and I can drill into them from there, vs blindly searching rules to update in /design.  

    /* Interfaces */

    rule!APP_formSubmit()

    rule!APP_formApprove()

    rule!APP_reportAdmin()

    /* expression rules */

    rule!APP_isViewer()

    rule!APP_isAdmin()

    rule!APP_getDataByUser()

    rule!APP_getDataById()

    /* constants */

    cons!APP_DS_REQUEST_DATA

    cons!APP_DS_CONTRACT_LOOKUP

    cons!APP_RUN_DAILY_NOTICE

    cons!APP_LINK_TRAINING

    ..etc.

Reply
  • Since developers don't see rules in the application based on a folder hierarchy, I'm not sure this would provide much benefit.  We just push for standard, logical naming conventions with an application prefix, and generally I will create objects something like below.  One of the current applications I'm working on contains 525 objects with 190 of those being expression rules, with them named properly (with DESCRIPTIONS!) I don't have much issue finding what I need.  Typically as well, I'm working through an interface or process model which shows me which rule(s) it's calling in the areas I'm updating anyway, and I can drill into them from there, vs blindly searching rules to update in /design.  

    /* Interfaces */

    rule!APP_formSubmit()

    rule!APP_formApprove()

    rule!APP_reportAdmin()

    /* expression rules */

    rule!APP_isViewer()

    rule!APP_isAdmin()

    rule!APP_getDataByUser()

    rule!APP_getDataById()

    /* constants */

    cons!APP_DS_REQUEST_DATA

    cons!APP_DS_CONTRACT_LOOKUP

    cons!APP_RUN_DAILY_NOTICE

    cons!APP_LINK_TRAINING

    ..etc.

Children
  • Certified Associate Developer
    in reply to Chris

    Right.. I was drawing some parallels to java packages with folders. Actually using folder structure will only help with hierarchical view which I guess isn't that great in the product currently. Also the object search doesn't really tell us which folder the object is from.

    While updating existing rules is an easy one. Building new ones by referring existing ones in them require some work. I think expression editor could use some enhancement for suggestion UI show what kind of rules are being listed (Different kind of rules can have same name) - which can be overcome probably with the rules naming convention.. 

    It appears rule naming is the only way.