This presentation is part of the Reusability and Specialization e-Learning Course.

Transcript

Requirements

In this scenario, we are working with a mortgage company that is asking us to specialize rules across a large group of 100+ brokers.  Each broker may maintain 10-20 rules on their own, with another 30-50 rules specialized for a broker by developers.  Security across brokers is of the utmost importance.  Seeing another broker’s rules is NOT allowed. 

Consider how class structure, RuleSets, and/or circumstances may play a role in your design, given this limited amount of information.

Approach

Given this limited amount of information, we can still come up with a proposed solution based on the guidelines I provided earlier.  Due to the security requirements, the use of circumstances to represent the rule specialization is likely not a good choice.  While not explicitly mentioned it would be safe to assume that persistence requirements would force different brokers’ data into different tables, perhaps even different databases, which is not possible with circumstances alone. 
Using RuleSets alone could be possible if no user would ever need access to two brokers’ rules.  This may or may not be true depending on the nature of the application.  However, RuleSets alone do not solve the persistence issue mentioned earlier. 

Using classes we are able to solve the persistence issue, as each broker could be in its own class group and thus map to its own database table and/or a separate database.  Rule customization can be done within that class group and security built to prevent the viewing of rules outside that class group.  Used along with separate RuleSets, this solution of using classes allows for each broker’s rules to be promoted independently from each other.  This is an example where classes are an obvious choice given the requirements that we know.