Using the Specification Pattern to Build a Data-Driven Rules Engine

Re:Using the Specification Pattern to Build a Data-Driven Ru... by BoiledCabbage on Tuesday March 24, 2020 @09:22AM (#22674599)

So many simple good ideas seem to come from Domain Driven Design.

[ Parent | on HN ]

Re:Using the Specification Pattern to Build a Data-Driven Ru... by pacala on Tuesday March 24, 2020 @12:40PM (#22676118)

Feeling cranky today, lockdown and everything. This is an elementary interpreter, clumsily implemented because of all the object oriented cruft.

[ Parent | on HN ]

Re:Using the Specification Pattern to Build a Data-Driven Ru... by agentultra on Tuesday March 24, 2020 @01:20PM (#22676541)

Indeed... in Haskell this can be implemented with a GADT and an evaluator which is really easy to express.

Still useful to know the "pattern" regardless of OOP cruft, Javascript prototypes, or Haskell data types.

[ Parent | on HN ]

Re:Using the Specification Pattern to Build a Data-Driven Ru... by quelltext on Tuesday March 24, 2020 @12:57PM (#22676301)

Don't you mean the Interpreter pattern /s

[ Parent | on HN ]

Re:Using the Specification Pattern to Build a Data-Driven Ru... by wpietri on Tuesday March 24, 2020 @02:11PM (#22677105)

Yeah, Evans' book really changed the way I do a bunch of design. That software is infinitely flexible is generally great, but it can allow complexity to metastasize. Anchoring design to the domain, which tends to be pretty stable, can provide a lot of clarity. It does require taking an anthropological approach to one's users, but I think that pays off in all sorts of ways.

[ Parent | on HN ]