If all you want to do is write a rule in one document and refer to it from a different rule in a different document, then you should not use Modules.
For example, imagine you have an age calculation rule (in Rule Document A) which calculates the person's age in years at the application date, e.g. the person's age in years = YearDifference(the person's date of birth, the application date)
And then you have a bunch of other rules in the project (in a variety of different rule docs) which require the person's age in years, e.g. the person is eligible for Benefit X if
the person's age in years >= 20 the person is eligible for Benefit Y if
the person's age in years >= 35 the person is eligible for Benefit Z if
the person's age in years >= 66
You can reference one rule from other rules simply by using the relevant attribute. In the example above, the rule calculating “the person’s age in years” is written once in one document (Rule Document A), and then that attribute is used as a condition in several other rules in different documents.
Hi Jasmine, I don't quite follow your response. Are you assuming that the question was asked from the perspective of a single rulebase? If there were multiple rulebases then using modules for aspects such as 'the person's age in years' appears to be a good idea - would you agree?
I also have a question here.
In OPA speak: the attribute is usable as a condition if the attribute originates in the project or the attribute is a top level attribute of a linked module
Is that a true statement?
or are you saying the attribute is usable as a condition if the attribute originates in the project
or something else? Can you make a rule for when to use attributes from shared modules, shared documents, etc? Can you make a rule for when to use multiple property files?
Of course, "rules are made to be broken". OPA just makes the task of breaking rules more interesting.
Any attribute in a module that has a public name can be used in a project using that module. So minimally you must be able to use top level and base level attributes in the consuming project for a module (you get warnings on module creation for anything you have not done this for in the same way you get warnings if you have the data model check on).
Intermediate attributes in a module without a public name will not be available in the consuming project (by not giving them a public name you've said "not relevant to anyone else"). But if you give them a public name then they are indeed available.
This (attributes without public names are not visible outside the module they originate in) even goes so far as that you can have an attribute with text "blah" in a module (eg created in project A) which is of type date (but no public name), you can then create an attribute with text "blah" in project B (which used the module from project A) which is of type number and OPA will be perfectly fine with it (or it was when I just tested it).
In a project you can use any attribute that has been declared (bearing in mind that booleans "self create").
So no, what you've said is not correct - an attribute is "useable" (or will appear as having already been declared in the data model) if it originates in the project or if it is declared as part of the module interface (by having been given a public name).
So for a module:
an attribute is available in a consuming project if it has a public name
a rule will be available in a consuming project if the conclusion has a public name and all* base level attributes have public names.
*I haven't explicitly checked this but it would violate all sorts of other built-in OPA principles (ie things that occur at compile/build time) that it would surprise me if it didn't need to be all.
In terms of your other questions...
Generally speaking if it doesn't cause a compile/build error then there are no "rules" in terms of what you can do in OPM (to distinguish rules development environment from what you might do in terms of implementation - ie OPA). There are certainly guidelines which get recommended about various things - but they'll have reasons behind them which should be tested against your specific development scenario. In the end most OPA guidance about how to develop in OPM comes down to what you're trying to achieve and balancing competing priorities. Beware of people who tell you something "must" be done in a particular way in OPM without explaining the why (actually generally beware of people like that in any sphere, not just OPM). You'll note that Jasmine's best practice guide is very much in that vein - here's a good way to do things, and (mostly) here's why (don't have time to re-read it now but that's my recollection - and not to speak on her behalf if she hasn't given the reason there will still be one but it was probably inappropriate for the flow/tone of the document - ie too much detail).
If by shared documents you mean "use something like symlink to share a document in multiple places" then I'd say that's bad and use modules (always - bearing mind what I just said about people telling you that something must always be done in a particular way). If by "shared" you mean "I have some concepts which as it happens I'm seeing for the first time in functional area X but are likely to be of use in functional area A, B, C" (eg person's age) then I'd say you would want to (think about) separate(ing) those out into (a) central document(s) (standard disclaimer on identifying and respecting definitional scope of terms and isomorphism etc, etc).
Multiple properties files are usually a response to a team development environment/larger project and the requirements of that development environment (source control, file storage, access rights, etc, etc) will have a big say about what you do.
Up until now, everything has been easily contained. Creating guidelines for management of the rules at a more "enterprise level" is becomming more important. That is where the rule sharing comes in, version control, etc.
It is good to get some more in-depth insight. We have read the help manuals, but with trial and error, sometimes it assists to have the information/theory explained more than once.
We would, of course, walk slowly and with reason before committing to a strategy.