By organizing your rule application as modular rule projects, you can improve the performance of Rule Designer for large rule applications, and facilitate the assignment of permissions in Decision Center.
Organizing business rules into rule projects
In Rule Designer, many operations take place at the rule project level, such as build, queries, refactoring, and ruleset extraction. Other operations, such as Content Assist and debugging, require browsing through all the rule project items. If you have many business rules in your rule project, these operations become slower.
The following diagram shows one rule project with two sets of business rules, Set A and Set B.
To avoid having to manage a large number of rule artifacts in your projects, try to break down your application into several rule projects. These rule projects must then reference each other. If possible, distribute the rule projects between multiple workspaces. Divide the business object model (BOM) among the multiple rule projects. Start the build process incrementally for each project, instead of building them all at the same time.
The following diagram demonstrates this modular organization. Here, you work with the Set A business rule artifacts separately from the Set B business rule artifacts as they are in separate rule projects.
Rule Designer performs better with this modular organization.
Organizing rule projects based on Decision Center permissions
In the Decision Center console, you can define permissions at the rule project level. To define permissions at the rule package level, however, you must specify the permissions programmatically. Therefore, if you organize your rule projects according to how you plan to define permissions, you do not need to define these permissions programmatically.
By default, in Decision Center, queries, branches, and extractors cover only the current project. However, you can modify this behavior in the Decision Center console to include referenced rule projects. Deployment baselines include all referenced projects that are necessary for deployment.
Organizing the BOM into rule projects
If a set of rules uses only a part of the business object model (BOM), you can consider isolating this set of rules and the part of the business object model into a separate rule project. Then, when you work with the rules, you have visibility only on the required BOM classes.
You can also split a large BOM entry into several smaller ones for more flexibility, as illustrated in the following figure.
When you work with a very large business object model, the completion menus in the Intellirule and Guided editors can become quite large. The size can be both a usability and a performance issue. To reduce the number of completion entries, and to make them more relevant to your rules, use categories. Categories are a good way to organize your vocabulary into subsets.
The following diagram shows such a rule project organization, called "diamond-shaped organization". In such organization, the rule project defines a rule flow and references child rule projects, which share a single rule project for the BOM.
If you decide to use a diamond-shaped organization, make sure that you define the ruleset parameters in the rule project that contains the BOM: if you define the same ruleset parameters in the child rule projects, these parameters appear as duplicates in the parent project.