Domain Specific Languages - a user view and an implementation view does expressiveness imply a compromise on the underlying domain model ?
Domain Specific Languages
-a user view and an
implementation view
does expressiveness imply a compromise on the
underlying domain model ?
Debasish Ghosh
@debasishg on twitter
Code @ http://github.com/debasishg
Blog @ Ruminations of a Programmer
http://debasishg.blogspot.com
Open Source Footprints
Committer in Akka (http://akka.io)
Owner/Founder of :! sjson (JSON serializati on library for Scala objects !
http://github.com/debasishg/sjson )
! scala-redis (Redis client for Scala !http://github.com/debasishg/scala -redis)
! scouchdb (Scala driver for Couchdb !http://github.com/debasishg/scouchdb )
model-view architecture of a DSL
how abstractions shape a DSL structure
choosing proper abstractions for compositionality
using proper language idioms
composing DSLs
model-view architecture of a DSL
how abstractions shape a DSL structure
choosing proper abstractions for compositionality
using proper language idioms
composing DSLs
ViewOr
Syntax
new_trade 'T-12435'for account 'acc-123'to buy 100 shares of 'IBM', at UnitPrice = 100,
Principal = 12000, Tax = 500
DSL
Model"
Semantic modelof the domain
view / syntax
is derived from
model
view / syntax
is a veneer of abstraction over
model
view / syntax
is decoupled thru an interpreter from
model
view / syntax
can be multiple over the same
model
# create instrumentinstrument = Instrument.new('Google')
instrument.quantity = 100
#create tradeTrade.new('T-12435','acc-123', :buy, instrument, 'unitprice' => 200, 'principal' => 120000, 'tax' => 5000
)
idiomatic Ruby API
new_trade 'T-12435'for account 'acc-123'to buy 100 shares of 'IBM', at UnitPrice = 100,
Principal = 12000, Tax = 500
add domain syntax
new_trade 'T-12435'for account 'acc-123'to buy 100 shares of'IBM', at UnitPrice = 100,
Principal = 12000, Tax = 500
add domain syntax
domain syntax
idiomatic Ruby model
interpreter
isolation layer between the model and the view of the DSL
def parse(dsl_string)dsl = dsl_string.clonedsl.gsub!(/=/, '=>')dsl.sub!(/and /, '')dsl.sub!(/at /, '')dsl.sub!(/for account /, ',')dsl.sub!(/to buy /, ', :buy, ')dsl.sub!(/(\d+) shares of ('.*?')/,'\1.shares.of(\2)')
puts dsldsl
end
Not all transformations can be done using simple regular expression
based string processing
model-view architecture of a DSL
how abstractions shape a DSL structure
choosing proper abstractions for compositionality
using proper language idioms
composing DSLs
" "
abstractions of the core domainmodel
layers of abstractions
" "abstractions of the core domainmodel
abstractions thatglue modelelements
layers of abstractions
combinators, façade objects, bridges & adapters
" "abstractions of the core domainmodel
abstractions thatglue modelelements
layers of abstractions
combinators, façade objects, bridges & adapters
domain specific embedded language
" "abstractions of the core domainmodel
abstractions thatglue modelelements
layers of abstractions
combinators, façade objects, bridges & adapters
domain specific embedded language
mo
del
vie
w
layers of abstractions ..
keep the underlying domain model cleanensure separation of concerns between the model and the view of the DSLyou can also implement the glue layer using a different programming language (polyglot programming)
withAccount(trade) { account => {settle(trade usingaccount.getClient
.getStandingRules
.filter(_.account == account)
.first)andThen journalize
}}
DSL in Scala over a Java domain model
withAccount(trade) { account => {
settle(trade usingaccount.getClient
.getStandingRules
.filter(_.account == account)
.first)andThen journalize
}}
DSL in Scala over a Java domain model
Java abstractions
withAccount(trade) { account => {
settle(trade usingaccount.getClient
.getStandingRules
.filter(_.account == account)
.first)andThen journalize
}}
DSL in Scala over a Java domain model
Java abstractions
Wired throughScala control structures
We need abstractions that generalize over computations ..
Our domain stocks, trades, bulls, bears ..
Security tradeExchange of securities and currencies (also known as Instruments)In the stock exchange (market)On a specified "trade date"Between counter partiesIn defined quantitiesAt market ratesResulting in a net cash value for the sellerOn the "value date"
Our domain stocks, trades, bulls, bears ..
Security tradeExchange of securities and currencies (also known as Instruments)In the stock exchange (market)On a specified "trade date"Between counter parties' accountsIn defined quantitiesAt market ratesResulting in a net cash value for the sellerOn the "value date"
// The Trade modelcase class Trade(account: Account, instrument: Instrument, referenceNo: String, market: Market,unitPrice: BigDecimal, quantity: BigDecimal, tradeDate: Date = Calendar.getInstance.getTime, valueDate: Option[Date] = None, taxFees: Option[List[(TaxFeeId, BigDecimal)]] =
None, netAmount: Option[BigDecimal] = None)
// various tax/fees to be paid when u do a tradesealed trait TaxFeeIdcase object TradeTax extends TaxFeeIdcase object Commission extends TaxFeeIdcase object VAT extends TaxFeeIdcase object Surcharge extends TaxFeeId
// computes value date of a tradeval valueDateProcessor: Trade => Trade = //.. impl
// computes tax/fee of a tradeval taxFeeProcessor: Trade => Trade = //.. Impl
// computes the net cash value of a tradeval netAmountProcessor: Trade => Trade = //.. impl
val trades = //.. list of security trades
// get a list of value dates for all tradesval valueDates = trades map (_.valueDate)
// enrich a trade passing it thru multiple processorsval richTrade = (valueDateProcessor map
taxFeeProcessor map netAmountProcessor) apply
trade
// pass a trade thru one specific processorval t = some(trade) map valueDateProcessor
val trades = //.. list of security trades
// get a list of value dates for all trades
val valueDates = trades map (_.valueDate)// enrich a trade passing it thru multiple processors
val richTrade = (valueDateProcessor map
taxFeeProcessor map
netAmountProcessor) apply trade
// pass a trade thru one specific processor
val t = some(trade) mapvalueDateProcessor
val trades = //.. list of security trades
// get a list of value dates for all trades
val valueDates = trades map (_.valueDate)
// enrich a trade passing it thru multiple processors
val richTrade = (valueDateProcessor maptaxFeeProcessor mapnetAmountProcessor) apply
trade
// pass a trade thru one specific processor
val t = some(trade) map valueDateProcessor
val trades = //.. list of security trades
// map across the list functorval valueDates = trades map (_.valueDate)
// map across the Function1 functorval richTrade = (valueDateProcessor map
taxFeeProcessor map netAmountProcessor) apply
trade
// map across an Option functorval t = some(trade) map valueDateProcessor
a map ..pimps abstractions to give us an ad hoc
polymorphism implementation on top of OO
a map is ..fundamentally powered by type classes
sealed trait MA[M[_], A] extends PimpedType[M[A]] {def map[B](f: A => B)(implicit t: Functor[M]): M[B] =t.fmap(value, f)
source: scalaz : https://github.com/scalaz/scalaz
a type class
a pimp
trait Functor[F[_]] extends InvariantFunctor[F] {def fmap[A, B](r: F[A], f: A => B): F[B]
}
source: scalaz : https://github.com/scalaz/scalaz
a functor is ..a type class for all things that can be mapped over
// map across the Function1 functorval richTrade = (valueDateProcessor map
taxFeeProcessor map netAmountProcessor) apply
trade
Function1[]implicit def Function1Functor[R] =
new Functor //..
the idea is to generalize abstractions ..
.. and by generalizing map over functors we get a combinator that can glue a large set of our domainabstractions
.. and this gives a feeling of uniformity in the DSL syntax
semantic model+
combinators=
DSL
model-view architecture of a DSL
how abstractions shape a DSL structure
choosing proper abstractions for compositionality
using proper language idioms
composing DSLs
a DSL ..
evolves from the model non-invasivelyusing combinatorsthat compose model elementsinterprets them into computations of the domain
so, a domain model also has to be ..
designed for compositionality
Image source: Mathematic al art of M. C. Escher (http://im-possible.info/english/articles/escher_math/escher_math.html)
domain rule ..
enrichment of trade is done in steps:
1.get the tax/fee ids for a trade2.calculate tax/fee values3.enrich trade with net cash amount
the DSL ..val enrich = for {
// get the tax/fee ids for a tradetaxFeeIds <- forTrade
// calculate tax fee valuestaxFeeValues <- taxFeeCalculate
// enrich trade with net cash amountnetAmount <- enrichTradeWith
}yield((taxFeeIds map taxFeeValues) map netAmount)
// enriching a tradetrade map enrich should equal( )
the DSL ..val enrich = for {
// get the tax/fee ids for a tradetaxFeeIds <- forTrade
// calculate tax fee valuestaxFeeValues <- taxFeeCalculate
// enrich trade with net cash amountnetAmount <- enrichTradeWith
}yield((taxFeeIds map taxFeeValues) map netAmount)
// enriching a tradetrade map enrich should equal( )
Model elementsthat can be composedusing the for-comprehension
reiterating ..
a combinator acts ..as a glue combining model elements
But ..
there is a prerequisite ..
model elements should be composable
we call this the compositionality of the model
Q: How to design your model
so that it's compositional ?
A: choose the right abstractions ..
depending on the programming paradigm(FP, OO ..) and the implementation
language used
domain rule ..
net cash value calculation of trade:
1.use strategy for specific markets, if available2.otherwise use default strategy3.we can supply specific strategy inline as well
the DSL ..// type alias for domain vocabularytype NetAmount = BigDecimaltype CashValueCalculationStrategy =PartialFunction[Market, Trade => NetAmount]
// declarative business logicval cashValueComputation: Trade => NetAmount = { trade => (forHongKong orElseforSingapore orElseforDefault)(trade.market)(trade)
}
the DSL ..val cashValue: Trade => CashValueCalculationStrategy => NetAmount{ trade => pf =>if (pf.isDefinedAt(trade.market))pf(trade.market)(trade)
else cashValueComputation(trade)}
PartialFunction is ..the secret sauce
all functions for specific and default computation
return PartialFunction
that offer combinators for chaining of abstractions ..
val forHongKong: CashValueCalculationStrategy = {case HongKong => { trade => //.. }
}
val forSingapore: CashValueCalculationStrategy = {case Singapore => { trade => //.. }
}
val forDefault: CashValueCalculationStrategy = {case _ => { trade => //.. }
}
model-view architecture of a DSL
how abstractions shape a DSL structure
choosing proper abstractions for compositionality
using proper language idioms
composing DSLs
choice of abstractions depends
on the programming language chosen for implementation of your DSL
always keep an eye on the paradigms that yourimplementation language supports and play to
the idioms of the language
domain rule ..
A trade needs to be enriched with a set of tax and feesbefore we calculate its net cash value
the Java way ..
// use the decorator patternnew CommissionDecorator(new TaxFeeDecorator(new Trade(..)));
public class Trade { //..
public class TaxFeeDecorator extends Trade {private Trade trade;//..
}public class CommissionDecorator extends Trade {private Trade trade;//..
}
the Java way ..
decorators and the decoratee share a common interfacestatically coupled through inheritancethe decorator usage syntax is outside-in
the Ruby way ..
## decorator patternTrade.new(..).with TaxFee, Commission
class Tradeattr_accessor ..def initialize ..def with(*args)args.inject(self) {|memo, val| memo.extend val
enddef value@principal
endend
the Ruby way ..
## mixinsmodule TaxFee## calculate taxfeedef valuesuper + ..
endend
## mixinsmodule Commission## calculate commissiondef valuesuper + ..
endend
the Ruby way ..
more dynamic compared to Javauses Ruby idioms of runtime meta-programmingdecorators don t statically extend the core abstraction
if we were to do the same in Clojure ..
## decorator pattern(with-tax-fee trade(with-values :tax 12)(with-values :commission 23))
(defmacro with-tax-fee"wrap a function in one or more decorators"[func & decorators]`(redef ~func (-> ~func ~@decorators)))
the Clojure way ..
more functional uses HOFfunction threading makes the decorator implementation almost trivialcontrol structure uses macros, which are compile time meta-programming artifacts (unlike Ruby) no run time overhead
model-view architecture of a DSL
how abstractions shape a DSL structure
choosing proper abstractions for compositionality
using proper language idioms
composing DSLs
if you thought DSLs grow through composition of abstractions ..
.. then the final DSL is the whole formed from the composition of its parts ..
and if the final DSL is also an abstraction ..
.. there's no reason we can compose it with another abstraction (aka another DSL) to form a bigger whole ..
trait TradeDsl {type T <: Tradedef enrich: PartialFunction[T,
T]
//.. other methods}
constrained abstract type
abstract method
trait FixedIncomeTradeDsl extends TradeDsl {type T = FixedIncomeTrade
import FixedIncomeTradingService._override def enrich: PartialFunction[T, T] = {
case t =>t.cashValue = cashValue(t)t.taxes = taxes(t)t.accruedInterest = accruedInterest(t)t
}}
object FixedIncomeTradeDslextends FixedIncomeTradeDsl
concrete type for fixed income trade
concrete definition forenrichment of fixed income trade
trait EquityTradeDsl extends TradeDsl {type T = EquityTrade
import EquityTradingService._override def enrich: PartialFunction[T, T] = {
case t =>t.cashValue = cashValue(t)t.taxes = taxes(t)t
}}
object EquityTradeDslextends EquityTradeDsl
concrete type for equity trade
concrete definition forenrichment of equity trade
.. and now a new market rule comes up that needs to be applied to all types of trades
.. you don t want to affect the core logic, since the rule is a temporary and promotional one and is likely to be discontinued after a few days ..
.. design the DSL for the new rule in such a way that you can plug in the semantics of all types of trade within it ..
and now the rule itself ..
Any trade on the New York Stock Exchange of principal value > 10,000 USD must have a discount of 10% of the principal on the net cash value.
trait MarketRuleDsl extends TradeDsl {val semantics: TradeDsltype T = semantics.Toverride def enrich: PartialFunction[T, T] = {
case t =>val tr = semantics.enrich(t)tr match {
case x if x.market == NYSE && x.principal > 1000 =>
tr.cashValue = tr.cashValue - tr.principal * 0.1
trcase x => x
}}
}
trait MarketRuleDsl extends TradeDsl {val semantics: TradeDsltype T = semantics.Toverride def enrich: PartialFunction[T, T] = {
case t =>val tr = semantics.enrich(t)tr match {
case x if x.market == NYSE && x.principal > 1000 =>
tr.cashValue = tr.cashValue - tr.principal * 0.1
trcase x => x
}}
}
polymorphic embedding
new business rule that actson top of the enriched trade
object EquityTradeMarketRuleDsl extends MarketRuleDsl {val semantics = EquityTradeDsl
}
object FixedIncomeTradeMarketRuleDsl extendsMarketRuleDsl {
val semantics = FixedIncomeTradeDsl}
pluggable composition of DSLs
plug-in the concrete semantics
import FixedIncomeTradeMarketRuleDsl._
withTrade(200 discount_bonds IBM
for_client NOMURAon NYSEat 72.ccy(USD)) {trade =>
Mailer(user) mail tradeLogger log trade
} cashValue
a sneak peek at the
fully composed DSL ..
Summary
A DSL has a syntax (for the user) and a model (for the implementer)
The syntax is the view designed on top of the model
The model needs to be clean and extensible to support seamless development of domain syntax
The model needs to be compositional so that various model elements can be glued together using combinators to make an expressive syntax