I use Google blog search (http://blogsearch.google.com/) to keep track of anyone blogging about Spring Batch. Usually, blog posts are ‘getting started guides’, with simple examples, which is understandable given the way our samples are organized. Our samples are indented to test nearly every framework feature in a real batch job, and serve as a form of functional test. This is good for developers that understand the framework and want to know how to use feature X, but not so good if you’re new to the framework. I always intended on creating a simple example, but I think the blogging community has been so good about creating them, I’m not sure we could add much value.

I’m slightly digressing though. I recently ran into a much different blog post about Spring Batch:

http://java-chimaera.blogspot.com/2008/11/spring-batch-domain-driven-design-in.html

The main theme of the post is that Spring Batch serves as almost a reference implementation for DDD:

“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.”

In nearly every presentation Dave or I has given about Spring Batch, we usually start describing the domain model, and express that Eric Evans’ book was highly influential in how we designed Spring Batch. I can’t begin to tell you how much this model changed from when we first start until 1.0. In the original model, Steps were called StepControllers, and so on. As we continued through development, they naturally began to evolve. We were very conscious of Evans’ concept of Ubiquitous Language, and as we noticed ourselves continuing to refer to a concept as something, we usually decided that the class should be called that, which ultimately let to the simple Job and Step in the framework today.

I could talk for days about the evolution of the domain model in Spring Batch, but in the interest of keeping this post reasonably sized, I’ll simply summarize by saying that DDD was a big driver in the creation of Spring Batch, and it’s interesting to me that others unrelated to the project can see this by simply inspecting the code. I think it speaks volumes for the approach.