8 Business Rules as Data
This chapter covers
- Modeling business rules as data
- Interpreters and DSLs
- Not over thinking it and just writing code
Java gets unfairly associated with the architectural patterns that were popular in the age when it rose to prominence. It gets made fun of for its cathedrals of inheritance and needless abstractions. For many devs, there wasn’t a problem that couldn’t be “solved” by adding another design pattern.
Java has evolved, yet the perceptions around how we should build, and what it costs to do so, linger in the community’s unconsciousness. Modern Java is lean and confident. Records and pattern matching have changed how we approach design. New patterns are available to us. Leveraging them starts with data.
8.1 Let’s start with an example
At MegaCorp, large customer accounts have dedicated sales teams. These teams help customers navigate complex contracts, issue special discounts, and so on. Their commission is tied to the type of accounts they manage and the value of the deals they cut, so which account ends up under which team is steeped in historical decision, shifting org charts, and petty in-fighting. There’re no clean rules like “everything in the USA is handled by the US based sales team.” If only! Instead, it’s based on arbitrary and ever-changing rules.