Igor's Blog

A constant goal of mine is to express intent while developing software systems. In the begging, I spent a lot of time trying to create a better Object Oriented Design hoping that the abstraction level would be enough to clearly represent a business model. Of course, this wasn't enough and I continue looking for better abstraction levels.

The next step was my obsession with Design Patterns and Frameworks. Common understanding of the problem, at least among developers helped a lot but business people still couldn't easily relate a system solution to the actual business model.

Continuing in that direction led me to discover the incredibly valuable book - Domain Driven Design and just a little later the somehow related concepts behind an interesting but not very popular framework called "Naked Objects". Domain Driven Design was huge advanced towards expressing intent and introduced an invaluable concept about ubiquitous language.

At that point, the level of abstraction was pretty good in relation to designing domain models, but specifying the behavior of a system was somehow problematic. Again, mostly a change in the perception and the way of thinking rather than technology advances led me to the concept of Behavior Driven Design. Specifying system behavior in an executable way was an impressive step but a little hard to achieve with the current static programming languages that most of the systems were build at that time.

Didn't take me long to discover the disruptive power of dynamic languages like Ruby and all meta programming concepts that came with them. Additionally, I discovered a much different way of designing APIs in the form of Fluent Interfaces. That allowed me to express business intent through a software solution in an almost natural english language form that business people could start understanding.

Interestingly enough, it turned out that even this is not enough because of a simple fact - business people use a natural language only to define different specific languages that better describe their business domains. Well, not surprisingly this realization led me to the concept of Domain Specific Languages (DSL).

After the initial euphoria of designing and implementing Domain Specific Languages, I start looking for the same impressive tool support that I was used to while working with other well established general purpose programming languages. It turned out that there is not a better time for that with current release of most of the main players in this area (Intentional Software, JetBrains, MS Oslo, Eclipse xText,...) delivering solutions for a really disruptive concept summarized as Language Workbenches.

In order to visually represent this path towards delivering better software solutions, I created "My Curve of Abstraction Towards - Expressing Intent & Ubiquitous Language"



I don't know if DSLs and Language Workbenches would be successful in practice, but those concepts would definitely change the way in which I approach and design software solutions. In most of the system that I have built until now I used programming languages to specify a domain model and the behavior of a system. Recently, however, I worked on software solutions that had to be model for domain evaluation. Basically, I used programming languages to define a business model definition and structure via other languages and notations, or so called Language Oriented Programing.



This is actually the topic in my presentation that I gave recently called - "Domain Specific Languages- ... a forgotten interface metaphor with renewed tooling support".

Labels: DSL, Redpoint