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 lives in the shadow of the language it’s perceived to be. It gets unfairly associated with patterns that were in vogue at the time it rose to prominence. We constructed cathedrals of inheritance, bizarre abstractions, and there wasn’t a problem that we couldn’t “solve” with a design pattern.
But the language is not the patterns. It never had to be that way.
Java has continued to evolve, but many developers are still living in its former shadow. 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 fundamentally changed how we approach design in Java. New patterns are available to us and leveraging them starts with data.
8.1 A few requirements
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.