This chapter is from the book
This chapter is from the book
This chapter is from the book
Decision as a Service
In the Decision-as-a-Service pattern (Figure 3-11), the logic necessary to make a decision is factored into a separate component. The service consumer gathers all relevant current-state input data for the decision and passes it to the service. This is typically a synchronous request-reply interaction, but it may be asynchronous. In either case, the decision service computes output data from the input data, using static reference data as appropriate. The output data reflects the decision results.
)
Figure 3-11: Decision-as-a-Service Pattern
The value of this pattern is that it encapsulates the logic of the decision as a service. This simplifies the maintenance of both the service consumer and the decision service. In particular, it allows the implementation of the service (that is, the business rules) to be updated without requiring a modification to the service consumer.
To make this possible, however, both the input and output data structures have to remain fixed.
Let’s consider an example from the banking world. A bank needs to evaluate applications for credit cards to determine whether a credit card should be issued and what the credit limit should be on the account. In this case, the same data structure is used for both the input and output, with the difference being that some of the field values are computed by the Credit Card Decision service. Figure 3-12 shows this data structure. The input data includes the applicant’s age, credit score, a flag indicating whether or not the applicant has a driver’s license, another flag indicating whether they are married, and the applicant’s income. The computed output values comprise a Boolean indicating whether the applicant is eligible, a field indicating the current status, and another field indicating the credit limit should the status be accepted.
){kind=link}
Figure 3-12: Credit Card Decision Service Data Structure
A decision table describing the logic for this service is shown in Figure 3-13. This example is developed using the TIBCO BusinessEvents® Decision Manager, which is described in Chapter 10. Each line of the table defines a set of conditions for the input values (the Condition Area) and the corresponding computed output values (the Action Area).
)
Figure 3-13: Decision Table for the Credit Card Decision Service
The Decision-as-a-Service pattern is useful when the business rules change frequently but the data used to drive the decision and the outputs of the decision can be fixed.