Sunday, 2 November 2008

Spring-Batch: Domain Driven Design in Action

Not long ago, Spring was the main promoter of AOP technology and gave it its real place in the enterprise landscape. Recently and with the release of Spring-Batch, which is in his own as a framework the first one in this category for the java environment (I don’t know if there is any other equivalent in other platforms), Spring tends to promote one of the most powerful concepts in application development : Domain Driven Design.

DDD emergence difficulties

In fact, although DDD is not a ‘new’ concept (the famous Eric Evans’ Book was published in 2004, and Martin Fowler speaks about it in 2003), its adoption is not equivalent to its importance and added value. This is ‘classically’ due to the absence of real promoters which could put it into action and demonstrate its powerful approach for a wide public.

Indeed, DDD is rarely invoked publicly, and even when it is the case, it is promoted by some evangelists who preaches, in my eyes, by elitism which means that the concept is ignored and neglected by the masses. Besides, there have been no good and interesting examples of its
application, for those who manifest their interest but have nothing concrete that can really demonstrate DDD. But the most principal obstacle (imho) is the harmful effect of the EJB design model and its related ‘patterns’, which is the actual main stream even for lightweight container based applications like Spring itself, and which promotes the anaemic domain model and the 'super’ service layer anti-patterns.

Spring-Batch: the savior?

By applying DDD in Spring Batch, we now have a realistic and elaborate example of concepts like ‘repository’, ‘factory’ or again the ‘ubiquitous language’. What’s also interesting in this implementation is that, by being a technical domain, developers can easily comprehend the concepts and identify them more easily. Talking about easiness, I noticed that a large number of people who have tried Spring-Batch find it a bit complex to use and they especially encounter some difficulties in finding the entry point to it. I think that this is due to the fact that they were accustomed to a traditional view of batch applications and haven’t taken the time to understand the way Spring-batch makes abstraction of all the common and traditional facets of a batch application.

I will not go into detail about what was done in this direction, because I think that it is very well treated on the official site or in the reference documentation or even in some online presentations, but I will say that by understanding the whys of this unusual way, we can realise all the powerful things that Spring-batch can offer.

In fact, to be simple and concise, Spring-Batch makes a very fine abstraction of a batch application and its execution flow and by doing so it permits not only the developer (or the user) to focalise on the specific steps of his job and their particular logic but also gives him a very powerful control facilities on what is done in these steps; for example, like the execution context which can hold information such as the number of processed items in any particular instant of the execution like a resource unavailability failure. Also note here, that it treats the steps in an item-oriented way which is one of the core reasons of these features and that’s why we must prefer it on the Tasklet solution which can be considered for refactoring legacy batches which cannot be easily adapted in the item-oriented way.

The Springframework new argument

Finally, and returning to the Springframework and the SpringSource, I just want to say that it seems to be that DDD will be the next Rod Johnson’s ‘War’ on EJB after the IoC one. And we can see that through the new features introduced into the 2.5 version, which takes benefits essentially from AspectJ power (and team!) to give technical solution to DDD patterns realisation; and also some presentations made by the Spring Team and essentially those of Rod Johnson and Ramnivas Laddad. After all, even EJB ‘prone’ now the lightweight model promoted by Spring and the IoC pattern (without being able of course ☺ ), and Mr. Rod was obliged to find another area where EJB really sucks.


  1. Hi Slim,

    well, I was at where Peter Cooper Ellis talked about a new product in the SpringSource roadmap Roo. A domain driven design code generation tool.
    This tool is created by ben Alex, main developper of spring security.

    The announce here :
    Some info about Root (not much) :

    See you at the next bar camp or parisjug !


  2. I've tried to find something on this, and all that I find is that Ben Alex will present it in SpringOne America

  3. This comment has been removed by a blog administrator.