DDDSample tutorial at QCon London

I'm very proud to announce that I will be giving a tutorial on the DDD sample application at QCon London in March next year, together with my colleague Patrik Fredriksson. The presentation will be basically the same as the one we're giving at the Swedish conference JFokus in January, but in English (obviously :-)).

Hope to see you there! The tutorial will cover the upcoming second release of the application.

On layering in DDDSample

There has been considerable interest in the DDDSample application on the Swedish DDD user group mailing list - people are scrutinizing the code, asking questions and raising concerns. This last week has been mostly about layers and packages, and I think this blog is a good forum to provide a little background and explain the rationale behind how the sample application is structured.

When we first started working on the application, we used a fairly standard layering with a web user interface layer, a service layer with interfaces, implementations, transaction demarcation and so on, and a repository layer for persistence, implemented in Hibernate (roughly matching the DAO layer found in most applications). These layers all resided in their own package hirearchy. In addition to that, the domain model had its own package, although it wasn't a layer in the usual sense - it was used by several other layers, but calls did not pass through the domain model on to some other layer. This suited us well for the time being, since there were many other aspects of the application that required our immediate attention.

As the application grew more mature, we began looking at how the structure of the application could illustrate important DDD concepts such as aggregates and isolating the domain. In his book, Eric Evans uses this diagram when talking about layered archicture:


By far the most important layer is the domain layer, so we decided to take a closer look at the contents of our domain layer and the domain package. A pretty obvious decision was to place each aggregate in its own subpackage below domain, so we had domain.cargo, domain.handling and so on. Deciding which services were domain services and which were application services was harder, but we settled for a separation where domain services performed tasks that you could talk about with a domain expert, using the ubiquitous language. Signatures consisted completely of domain model types. In some cases, it was natural to place the interface of a domain service in the domain layer, but the implementation elsewhere.

But the decision that would turn out to be the most controversial was placing the repository definitions (i.e. the interfaces) in the domain layer, alongside the aggregate root for which it was used to retrieve, store and search. The concept of an aggregate root is closely linked to that of a repository: all access to an aggregate is through the root, so consequently the repository works with aggregate roots, and there is one repository per aggregate root (and thus per aggregate). Also, repositories are expressed in the ubiquitous language.

At this point our domain layer consisted of the domain model, separated into aggregates, domain services and one repository per aggregate, which we felt pretty good about (and still do). It expressed many important DDD concepts in a clear way, and it was slightly unorthodox compared to many mainstream designs. All this was located under the domain package.

The question of what to do with the rest of the application remained. The other three layers are not as interesting from a DDD perspective, so we decided not to pursue the effort of organizing the rest of the code into per-layer-package hierarchies, but instead separate it from the domain package and organize it by a combination of technology and use cases.

We did however consciously include two very different approaches to user interface exposure. The tracking web interface, which runs in the same JVM as the main application, is the low-overhead-thight-coupling way of doing it (in terms of layers and lines of code), where the MVC controller acts as application layer and calls the domain layer repository directly. The tracked cargo is thinly wrapped in the view rendering phase to make it easier to work with in a JSP EL environment.

The booking web interface on the other hand can run in a different JVM and works against an RMI facade on top of the domain layer, passing custom DTOs back and forth. The point is that we don't generally recommend a mandatory, slavishly delegating application layer between the presentation and the domain layers. Sometimes the controller in the MVC layer can play the part of application just as well. Another important point here is that you should always shield the domain model objects from presentation requirements, and DTOs or a thin presentation wrapper and so on are good options for doing that.

The top level package for all non-domain-layer code was named application, which turned out to be a bad idea (mine) since the name coincided with one the the layers in the picture above. For the record, the rationale behind it was "application" as in "computer program", i.e. everything about the code that wasn't part of the domain. A better name would have been something like nondomain or even other.

This problem immediately became apparent when I presented the application to the New York DDD User Group, so a separate ui package was extracted for the web MVC controllers and supporting code. This actually turned out to make matters slightly worse, since we now had top-level packages with names matching three out of the four layers in the DDD layer model, immediatly leading people to ask for the missing infrastructure package. The discussions on the mailing list and other forums helped us realize that there is a need for an explicit infrastructure package, so the next version of DDDSample will include such a package containing the parts that we consider to be part of the infrastructure layer.

It appears from the discussions on the Swedish user group mailing list that many people think of the infrastructure as being identical to the persistence aspect (the database and the O/R mapper), but we have a wider definition of infrastructure which also includes messaging, scheduling, thread pools, the Spring container, the servlet container and external services such as mail senders and in our case the routing team's graph path finding service.

Looking at the picture above, the arrows between the layers actually illustrate the point quite well: the presentation, service and domain layers all work with the infrastructure layer, but it's important to realize that it doesn't mean that you should execute SQL statements in your JSP pages, but rather that each layer interacts with some part of the infrastructure. Also, the infrastructure layer can be used for passing asynchronous messages between layers.

In general, we consider code and configuration files that we write in order to hook into the infrastructure to be part of the infrastructure layer - Hibernate repository implementations, HBM mapping files, Spring context definition files, the RoutingService implementation and so on. Sometimes the distinction is harder to make, such as having an application service implement the JMS MessageListener interface to act message-driven.

As a rule of thumb, never state rules of thumb when it comes to software development. But if I were to do that anyway, I'd say that the infrastructure layer should be completely separable from the rest of the application by stubbing out external services, implementing persistence in-memory, and using synchronous calls or simple threads for messaging.

DDD updates

For about a year now, I've been part of a team at Citerus that has worked with Eric Evans to create a sample application showcasing domain-driven design, and we have recently released the first version to the public.

Al least two porting efforts have already been initiated: Qi4J and Sculptor. Some people are blogging and twittering about it, too :-)

The Swedish DDD user group held its first meeting at the Omegapoint office in Stockholm, where Patrik Fredriksson and I presented the application. In August I presented the application to the New York DDD user group, and in January 2009 we will give a three-hour tutorial on basic DDD and the sample application during the JFokus conference.

On tuesday, November 4, Eric Evans and Patrik Fredriksson will host a one-day seminar on DDD in Stockholm.

DSL for time and money

(Well, for time anyway)

A couple of weeks ago, I did some work together with Eric Evans when he came to Uppsala to give his excellent course in domain driven design, which was co-hosted by Citerus and Patrik Fredriksson.

Eric is the project leader of the Time and Money Java library, which makes working with dates, time intervals, currencies and so on a breeze. However, inspired by this article by Guillame Laforge, I wanted to see if I could create something similar by leveraging Groovy and the Time and Money library. These are a few simple examples that I came up with in an hour:

println 1.minute

=> '1 minute'


println 5.minutes + 1.minutes

=> '6 minutes'


println "2003-05-16" + 3.weeks - 50.years

=> 'Sat Jun 06 01:00:00 CET 1953'

Looking at these statements from top to bottom, we first have

1.minute

The number 1 is of course an instance of java.lang.Integer, a full-blown object. On that instance, we access something called minute, which kind of looks like a field, but is actually a JavaBean property thanks to Groovy's built-in support for those. So what we really have is an invocation of Integer.getMinute(), a method that doesn't exist. But don't worry - here's how we can use metaprogramming to add that method to the Integer class:

Integer.metaClass.getProperty = {symbol ->
switch (symbol) {
    case ["minute"]:
        return Duration.minutes(delegate)
    default:
        return null
}
}

In Groovy, every class has a corresponding open metaclass, the ExpandoMetaClass, that may be used to dynamically add methods on classes. The method getProperty is invoked when a JavaBean property is accessed, and here we assign a closure to be evaluated on invocation. The closure recieves one argument, symbol, which is a String containing the name of the property accessed, in this case "minute". This particular case is chosen to be converted to a Time and Money datatype, Duration, by passing the delegate (that's the instance we're invoking the getter on, i.e. 1) to the appropriate factory method. The result is that a Duration instance is returned, representing one minute.

Moving on to the next one, we have

5.minutes + 1.minute

The terms being added are familiar by now, although we need to expand the previous closure to this:

Integer.metaClass.getProperty = {symbol ->
switch (symbol) {
    case ["minute"]:
        return Duration.minutes(delegate)
    case ["years", "quarters", "months", "weeks", "days", "hours", "minutes", "seconds"]:
        return Duration.getMethod(symbol, int).invoke(null, delegate)
    default:
        return null
}
}

Fortunately, the Time and Money library has nicely named methods that correspond exactly to how we want to express durations in this DSL, so we can be very efficient and use reflection invocation of factory methods. Oh, and it's very nice to be able to switch on lists, isn't it? :-)

But there's one more thing to it: the overloading of the + operator. We've already established that both 1.minute and 5.minutes are instances of Duration, and luckily the Duration class already has a plus(Duration) method on it, that Groovy will automatically evalute. It's not always the case that there is such a method available though, as we find out when we move on to the third case:

"2003-05-16" + 3.weeks - 50.years

Evaluating from left to right, we're initially adding a String and a Duration, but String does not have any plus(Duration) method, so we're going to have to add that:

String.metaClass.plus = {Duration duration ->
return duration.addedTo(TimePoint.parseGMTFrom(delegate, "yyyy-MM-dd"))
}

Here, we're using the Time and Money API to represent the String as a TimePoint, to which a Duration may be added, producing another TimePoint. Continuing our evaluation, we now have to subtract a Duration from a TimePoint, which should be quite familiar by now:

TimePoint.metaClass.minus = {Duration duration ->
return duration.subtractedFrom(delegate)
}

These are just a few examples, and the possibilities are vast.

Grails Pet Store 0.2 released

I finally managed to wrap up a semi-stable milestone of Grails Pet Store, and the roadmap is now available in the form of tagged issues. Hopefully there will be a live instance available Real Soon - watch this spot for updates.

Podcast from JFokus available

The JFokus presentations are finally available online. Both my presentation on Grails and my collegue Patrik Fredriksson's presentation on the specification pattern are available here. Type your name, press login, then press Play on the next page. Don't ignore the yellow information box if you're running Mac :-)

Damn you DBUnit!

I simply can't get over how powerful the Groovy XML and SQL support is, especially when you combine the two. Did you ever find yourself in the position where you wanted to convert a Hypersonic database to a DBUnit dataset? I did, and I told my co-worker, somewhat disgruntled, that "I bet this could be done with 30 lines of Groovy". Well, it could:

import groovy.sql.Sql
import groovy.xml.MarkupBuilder

def sql = Sql.newInstance("jdbc:hsqldb:my_db", "sa", "", "org.hsqldb.jdbcDriver")

def sw = new StringWriter()
def xml = new MarkupBuilder(sw)

xml.dataset {
   sql.eachRow "select * from system_tables where table_type != 'SYSTEM TABLE'", {
       table(name:it.TABLE_NAME.toLowerCase()) {
           sql.rows("select * from ${t}", { md ->
               md.columnCount.times {
                   column md.getColumnName(it + 1).toLowerCase() ?: ""
               }
           }).each { r ->
               row {
                   r.size().times {
                       value r[it]
                   }
               }
           }
       }
   }
}

println sw

This is why I like Groovy - it's powerful, yet elegant.

Groovy power

The concurrent API that was added to Java 5 is very powerful for sumbitting tasks to a worker thread pool, but when you combine it with the Groovy ability to implement single-method interfaces with closures you have a real winner.

import java.util.concurrent.Callable
import java.util.concurrent.Executors

def executorService = Executors.newFixedThreadPool(4)

def x = {
   20.times {
       println "X"
   }
} as Callable

def y = {
   20.times {
       println " Y"
   }
} as Callable

executorService.invokeAll([x, y])

executorService.shutdown()

which of course has an output similar to this:

X
 Y
 Y
 Y
X
 Y
X
 Y
X
 Y
 Y
X
X
 Y
X
 Y
 Y
X
X
X

Pretty neat, huh?