14 Implementing business rules

 

This chapter covers

  • Evolving our example DSL for writing business rules
  • 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. Figure 14.1 shows an example of some business logic defined as a business rule. (This figure is a screenshot of a part of the Domain IDE that we’ll have built by the end of this chapter.)

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

This business rule expresses that when the rental period contains a Saturday, 10% is to be added to the discount. For a lot of domains, a major part of business logic can be 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 The execution model of business rules

14.2.4 Changing the Runtime

14.2.5 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

Summary