Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,128 | Comments: 45,550

filter by tags archive

ChallengeDon't stop with the first DSL abstraction

time to read 1 min | 174 words

I was having a discussion today about the way business rules are implemented. And large part of the discussion was focused on trying to get a specific behavior in a specific circumstance. As usual, I am going to use a totally different example, which might not be as brutal in its focus as the real one.

We have a set of business rules that relate to what is going to happen to a customer in certain situations. For example, we might have the following:

upon bounced_check or refused_credit:
	if customer.TotalPurchases > 10000: # preferred
		call_the cops

upon new_order:
	if customer.TotalPurchases > 10000: # preferred
		apply_discount 5.precent
upon order_shipped:
send_marketing_stuff unless customer.RequestedNoSpam

What is this code crying for? Here is a hint, it is not the introduction of IsPreferred, although that would be welcome.

I am interested in hearing what you will have to say in this matter.

And as a total non sequitur, cockroaches at Starbucks, yuck.

More posts in "Challenge" series:

  1. (28 Apr 2015) What is the meaning of this change?
  2. (26 Sep 2013) Spot the bug
  3. (27 May 2013) The problem of locking down tasks…
  4. (17 Oct 2011) Minimum number of round trips
  5. (23 Aug 2011) Recent Comments with Future Posts
  6. (02 Aug 2011) Modifying execution approaches
  7. (29 Apr 2011) Stop the leaks
  8. (23 Dec 2010) This code should never hit production
  9. (17 Dec 2010) Your own ThreadLocal
  10. (03 Dec 2010) Querying relative information with RavenDB
  11. (29 Jun 2010) Find the bug
  12. (23 Jun 2010) Dynamically dynamic
  13. (28 Apr 2010) What killed the application?
  14. (19 Mar 2010) What does this code do?
  15. (04 Mar 2010) Robust enumeration over external code
  16. (16 Feb 2010) Premature optimization, and all of that…
  17. (12 Feb 2010) Efficient querying
  18. (10 Feb 2010) Find the resource leak
  19. (21 Oct 2009) Can you spot the bug?
  20. (18 Oct 2009) Why is this wrong?
  21. (17 Oct 2009) Write the check in comment
  22. (15 Sep 2009) NH Prof Exporting Reports
  23. (02 Sep 2009) The lazy loaded inheritance many to one association OR/M conundrum
  24. (01 Sep 2009) Why isn’t select broken?
  25. (06 Aug 2009) Find the bug fixes
  26. (26 May 2009) Find the bug
  27. (14 May 2009) multi threaded test failure
  28. (11 May 2009) The regex that doesn’t match
  29. (24 Mar 2009) probability based selection
  30. (13 Mar 2009) C# Rewriting
  31. (18 Feb 2009) write a self extracting program
  32. (04 Sep 2008) Don't stop with the first DSL abstraction
  33. (02 Aug 2008) What is the problem?
  34. (28 Jul 2008) What does this code do?
  35. (26 Jul 2008) Find the bug fix
  36. (05 Jul 2008) Find the deadlock
  37. (03 Jul 2008) Find the bug
  38. (02 Jul 2008) What is wrong with this code
  39. (05 Jun 2008) why did the tests fail?
  40. (27 May 2008) Striving for better syntax
  41. (13 Apr 2008) calling generics without the generic type
  42. (12 Apr 2008) The directory tree
  43. (24 Mar 2008) Find the version
  44. (21 Jan 2008) Strongly typing weakly typed code
  45. (28 Jun 2007) Windsor Null Object Dependency Facility



let preferred_customer = customer.TotalPurchases > 10000 ?


Is there anyway to get your pre-release copy of your "Building DSL in Boo"? I'm completely lost in DSL world, and it extremely lacks of resources out there.

Ayende Rahien


If you click on the book link on the side bar, you will go to a site where you can buy a PDF copy of the pre release version.

Ayende Rahien


No, I try no to do things twice.

Ayende Rahien


As I mentioned, this is a valuable part, but not by far the most important thing.


the unless part? :)

upon bounced_check or refused_credit:

        ask_authorizatin_for_more_credit unless IsNotPrefered

        call_the cops unless Prefered

upon new_order:

        apply_discount 5.precent unless IsNotPrefered

upon order_shipped:

     send_marketing_stuff unless customer.RequestedNoSpam

This way it's more uniform = easier for a parsing engine... or even a gui...


You saw cockroaches at Starbucks? Did you call the environmental services?

Benny Thomas

I'm no DSL man, but this seems a bit odd:

upon order_shipped:

send_marketing_stuff unless customer.RequestedNoSpam

Every other place you are using if, and suddenly you are using unless. Inkonsistence in my world.

But i miss order handling stuff in your DSL, everything is about a customer, but nothing about the order.


I have no experience with DSLs, but I sense something there I cannot quite wrap my brain around. Some things that I would toy around with:

1) bouncedcheck and refusedcredit could probably be combined into some sort of payment_failed object or state on the order.

2) I would really like to keep things focused on the order instead of both the customer and the order, like Benny mentioned. Perhaps setting a "doNotSendMarketingStuff" property on the order (this would also allow you to track the history of a customer's "nospam" setting, to a point).

Actually, I do not even like my second point. I am back to square one.


Maybe having a look at Specifications. by Eric Evans evans@acm.org and Martin Fowler fowler@acm.org






If number of rules grow, this DSL will be long as the river of amazon.

Joseph Gutierrez

Try this:

askauthorizationformorecredit with preferred

upon bouncedcheck or refusedcredit:

callthecops without preferred

upon bouncedcheck or refusedcredit:

apply_discount 5.precent with preferred

upon new_order

sendmarketingstuff unless customer.RequestedNoSpam

upon order_shipped

Ayende Rahien


Your approach is somewhat better, but still suffers from the same fundamental issue


Perhaps something roughly like this (excuse any bad syntax):

def: preferredcustomerstatus

paymentfailed = askauthorization_formorecredit

discount = 5.percent

end def

def: regularcustomerstatus

paymentfailed = callthe_cops

discount = 0.percent

end def

Then you would apply the rules as such:

if customer.TotalPurchases > 10000:

customerstatus = preferredcustomer_status


customerstatus = regularcustomer_Status

upon bouncedcheck or refusedcredit:


upon new_order:

applydiscount customerstatus.discount

upon order_shipped:

 send_marketing_stuff unless customer.RequestedNoSpam
Ayende Rahien


I hate the syntax, but you got the right idea

Tobin Harris

How about the ability to vary the language to make it read more naturally?

This might mean adding synonyms.

Also, you could have "fluff" keywords that make it read better but which are ignored by the interpreter.

This could be a totally terrible idea, I'm just thinking out loud :)


when a bouncedcheck arrives or refusedcredit:

if customer.TotalPurchases > 10000: # preferred



    call_the cops

when a new_order arrives:

if customer.TotalPurchases > 10000: # preferred

    apply_discount of 5.precent

when order_shipped happens:

 send_marketing_stuff unless the customer.RequestedNoSpam


else => otherwise

Ignored Words (fluff keywords)






Ayende Rahien

That is just playing with the syntax, and not really changing the abstraction


From your reply to Gilligan, I reckon that you think this snippet should convey chunked concepts like "preferred customers get 5 percent discount and extra credit" and "regular customers don't get no discount and we set feds after 'em soon as they try to f*ck with us".

I'm not sure the users of this DSL will be able to grok the non-trivial concept of introducing new "thingies" into the DSL, and using them later. That's a very code-ish concept: declaration and usage.

Ayende Rahien

See the next post to see how I think we can introduce it.

A scenario with actions based on this scenario is actually very easy to explain


C#: The ultimate DSL rules engine

It seems somewhat simple to split things up to make a fluent interface in C# that makes sense. But this is much more work.

Comment preview

Comments have been closed on this topic.


  1. The worker pattern - about one day from now

There are posts all the way to May 30, 2016


  1. The design of RavenDB 4.0 (14):
    26 May 2016 - The client side
  2. RavenDB 3.5 whirl wind tour (14):
    25 May 2016 - Got anything to declare, ya smuggler?
  3. Tasks for the new comer (2):
    15 Apr 2016 - Quartz.NET with RavenDB
  4. Code through the looking glass (5):
    18 Mar 2016 - And a linear search to rule them
  5. Find the bug (8):
    29 Feb 2016 - When you can't rely on your own identity
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats