chapter fourteen

14 Implementing business rules

 

This chapter covers

  • Evolving the example DSL to write business rules with
  • Implementing business rules
  • Generating code for running business rules

Our example DSL allows us to define a (single) record type in a type-safe way, and to generate a Runtime UI from that. That’s useful but not very valuable yet. It’s especially weird that the user of the UI is able to set the discount themselves. The discount should be computed by the Runtime based on logic defined by the business.

In chapter 1, I promised that we’d be building a DSL with which domain experts could write down business logic. The following Figure shows an example of some business logic defined as a business rule:

Figure 14.1. Some business logic, in the form of a business rule
business rule 1

(This Figure is a screenshot of a part of the Domain IDE that we’ll have built by the end of this chapter.) This business rule expresses that when the rental period contains a Saturday, then 10% is to be added to the discount. For a lot of domains, a major part of business logic can be very well expressed as business rules. Being able to specify business rules with a DSL brings a lot of power, regardless of the domain.

14.1 Extending the DSL with business rules

14.1.1 Defining business rules

14.1.2 Writing logical expressions

14.1.3 Defining consequences

14.2 Implementing the business rules in the Runtime

14.2.1 Running each business rule separately

14.2.2 Combining effects

14.2.3 Changing the Runtime

14.2.4 Generalizing the implementation

14.3 Generating the business rules' code

14.3.1 Identifying affected attributes

14.3.2 Generating, and using the rulesEffects method

14.3.3 Adapting the UI of affected attributes

14.4 Summary