In my first Language-Oriented Programming essay I’ve established a parallel between language domains and Meilir Page-Jones class Domains. At this text I’ll try to adapt Page-Jones’ concepts to the current development environment we have.

Page-Jones writes about how some classes have in common the fact that they would be more or less reused according to how they are related to a context defined by a single system. The closer to that context a class is the least reusable it is. By that classification he states that classes like the representation of dates, integers and strings belong to the same group and he calls those group Domains.

“Domain” is certainly a overloaded word in computer science, it can have different meanings depending on what we are talking about, but between Page-Jones’ Domains and the Domain concept in Domain-Specific Languages there is no big difference.

The book is an introductory Object-Orientation guide, it is full of information on what makes an Object-Oriented project good or bad. Page-Jones groups classes into Domains much as the concept used by the software reusability community in middle-1990 -when the industry was crazy about objects and reusability. That concept was summarized by van Deursen and Klint as:

…Following Simos (1995, 1996), two definitions of domain could be used. The first is generally used in the artificial intelligence and object-oriented communities. It lets a domain correspond to the “real world”, without direct relation to software systems it might be encoded in. The second definition comes from the systematic software reuse research community. It defines a domain as “a set of systems including common functionality in a specified area”.

- Arie van Deursen/Paul Klint, Little Languages: Little Maintenance?

Domains in DSL-speak is the context a piece of the software system works with. A system will have lots of domains and some of them will be key aspects of the system like business rules processing or handling user input. Other Domains are simpler like handling text and performing arithmetics

If you think of DSL Domains you will see that almost always one DSL Domain will fit into only one of Page-Jones’ Domains. We can say that page-Jone’s Domains are superset of DSL Domains grouped by the reusability they have.

I think that the real useful metric we can get from Page-Jones’ classification is not about reusability at all, reusability level is a side-effect. The real useful feature is that it tells us if a Domain is tied to the concepts from a single application or if it is more generic and therefore if a Language aimed at that Domain would be specific to that application or business or would be generic and could be used in lots of other systems.

I think that those reusability-driven groups act like Layers in a system. Layers as defined by Fowler groups component with related responsibility in a system and act as a dependency control mechanism therefore I will use the term “the Layer of a Domain” to refer to the measure of how this Domain is generic or tied to a specific application.

Standard Layers

The Layers -or Domains by his nomenclature- defined by Meilir Page-Jones are very complete. I couldn’t think of a Domain that wouldn’t fall into one of those but certainly this is a possibility. I present the Layers defined by Page-Jones as the Standard Layers.

There are some interesting characteristics of those Layers:

• They aren’t opaque: Languages at higher Layers can access any of the lower Layers or Object Domains, not only the one directly bellows it.
• They are accessed top-down:A language at a lower Layer can’t access resources and concepts at upper Layers.

Fundamental Layer

The concepts at this Layer are basic to any software systems, they could be used in almost all architectures, all business and all kind of applications.

Common concepts at this domain are database querying, regular expressions, context-free math, text manipulation, I/O and even more sophisticated matters like HTTP request handling or Object-Relational Mapping.

Architecture Layer

Page-Jones states the Architecture Domain as a place where differences and idiosyncrasies between computer architectures are solved. At the time that book was written there were lots of different computer architectures around and each one provided its way of doing things like persisting data, inter-process communication and the like. At that time a system architecture was more about choosing what kind of storage it would use (relational, hierarchical, object-oriented…), IPC mechanisms (raw sockets, pipes, …) or even the window toolkit (AWT, Qt, GTK, MFC…) than about what we now consider architecture: the components of a system and how they relate to each other. This said I think it’s time to get the Architecture Layer to the present.

This Layer’s components defines how the system is structured. The concepts at this Layer are related to a single architecture and are useful only in that context.

A good example of this Layer is presented by Ruby on Rails, a framework that allows applications to be built in a specific architectural style.

Business Layer

The components of this Layer are useful in a given business domain. This Layer will define concepts that would be useful in lots of different applications that share the same business.

An example of what you could find at this level would be a class named Customer. This class can be used in a Customer Management system where you register customer data, the actual sales system where you report that a customer has bought something and a customer relationship management application where you control all your marketing efforts. Those three applications deal with different activities but they all share the concept of a customer. This concept is related to the business as a whole, not to a given application only.

Application Layer

At this level we have concepts and components that are specific to a given application. They will not be useful for any other application, even from the same business.

Examples of this Layer are components that handle certain events. For example you could have a component that would receive a signal that the user is going to add a customer and handle the information and the workflow for that action. This component would be useless in other application that wasn’t related to customer register.

Domain Layers and Domain-Specific Languages

A Domain contains components. Components can be anything capable of performing actions one would expect from a computer program. In Object-Oriented terms components would probably be classes or objects. In Language-Oriented Programming they could also be languages.

As said above a Layer will have different Domains. A Domain-Specific Language can handle one or more of those providing a vivid representation of the concepts in that Domain.

During the history of computer science we have built languages for lots of different Domains besides our General Purpose Languages. If you follow those you will see that much of the languages we have created are in the Fundamental level (SQL, HQL, RegExp and dozens of mathematical languages for example). Early programming environments didn’t provide a productive way of performing event he most basic actions so we started from the very basics.

Currently we found out that our sophisticated architectures are too complex to be productive. We have flexibility and power but it is very hard to put the right pieces to work so we have found things like Spring, Castle or Ruby on Rails to make this work easier.

Now it is time to the Business and Application-level Domain-Specific Languages.

Of course it is currently improbable to have an application that would use DSLs for all its Layers. Current technology provides us with languages to deal with lots of problems and to build up our own language but that doesn’t mean all tasks would be performed by a DSL. This can be good, indeed, since we need a base language -generally a GPL- or we would have to know dozens of programming languages to write a simple application.

History

• 10/29/2007 - First Draft