Your ESB is going to kill you

Recently I wrote about the fruitless plight of a schizophrenic service.  Now, I think that some of that schizophrenia exists in the ESB too (or is it rubbing off onto the ESB?).  I’ve always felt that the ESB was just another pattern that showed how to isolate things and deal with routing and transformations.  The most common implementation was a messaging gadget with some pluggable framework of sorts for the transformations, and some configurable framework for routing.
With such isolation of parts, it was convenient to not worry about what happened elsewhere when something was thrown to this gadget for processing.  And we started wondering about scalability things and decided that asynchronous was the way to go … disconnected, stateless, etc, all good, well-intentioned things and useful things.

Then the pattern became a product.  And on top of this product we had more products like business process orchestrators or workflow managers.  And below this product we had applications and databases and ftp locations and all sorts of things that catered for every imaginable protocol.  And around all of this we had some enterprise-ish sort of management thing to keep on eye on everything that was happening inside this very busy product.

Then, services moved from applications to the ESB product.  After all, it’s a service and that’s an enterprise service bus, right?  And when the services where moved over to their new home, all the dependencies had to come along too.  And then we started arguing about getting granularity right in the ESB.  I used to just think that the ESB had a proxy of sorts to the service that still was at the application.  Maybe I got it all wrong.

Now this ESB is starting to feel like an Application Server with a messaging gadget, workflow gadget, transformers, routers, protocol handlers.  And some ESB’s have a web server too, since they have browser based management consoles.

Some people also like the idea of a rules engine for their complex domain rules and embedded those in their applications.  Hold on, those content based routers in the ESB also used a rules engine.  Ok, let’s move our rules over to the ESB too.  Cool, my ESB is also a rules engine.

Now, I see people writing the most hellish XML that is meant to do everything from configure routing, define transformations, execute code, persist messages, fire off sets of rules and more.  It reminds me so much of those weird and wonderful stored procedures and cascading triggers that we wrote.  The other day I got a laugh out of a friend when I told him that ESB’s are now DB servers and everyone writes sprocs in XML.

And we tried to do everything in the database server – rules, custom types, defaults, constraints, sprocs, triggers, batch jobs … even jump into a shell and execute something else.  It did not work out very well then.

If I was an ESB, I’d be very confused.  I started life as a pattern with a reasonable implementation using messaging and transformation and routing.  Now all of this.  In fact, I’d be more stressed than confused.

Then again, maybe the ESB is not confused, and maybe the people that use the ESB that are confused.  In fact, if I was one of those people, I’d be stressed too.

Fast Track to Domain Driven Design

I finally got out of neutral and pulled together the first public offering our Domain Driven Design courses in Cape Town, South Africa.  Normally we give these courses on-site with people on the same development team but I thought it may be fun and inspiring to open it up to everyone for a change.  Now I’m all excited again and really looking forward to a diverse mixture of people. Hopefully, I will see some old faces and lots of new people.
The one thing I can tell you is that the course is a very immersive experience.  I really hate lecturing but I enjoy probing conversations and that’s how I give the course. I don’t have answers to the practical work and concerns are addressed as we go along.  As a result, the day takes unexpected turns and routes.  But in the end I get you to the right destination.  Come along; you will leave exhausted, but inspired!

Take the Fast Track to Domain Driven Design

about the coursecourse contents / should you attend? / register for the course

factor10 has expanded its services in South Africa to include our advanced and
expert level courses aimed for the software professional.  On September 8-9, 2009,
we will be offering a fast track to DDD for Architects at the BMW Pavilion in
Cape Town.


Who should attend?

This course is for software professionals that want to take the right steps towards
advanced and expert levels in their careers.  Register for this course if you want to …

  • learn more than just another syntax and set of tools
  • write software for large, long living systems
  • increase the quality and maintainability of your design
  • design high quality models and use code to represent those models effectively
  • develop applications with a good APIs
  • add a design edge to your skill set


Why should you learn DDD?

More and more developers and architects realise that learning every detail of a new
API just isn’t the way to deliver the best business value. It’s such a tough balancing
act; focus on the solving the business problem and focus on building working software
with your frameworks.

One way of taking a big leap in the right direction is to learn and apply domain driven
design. It is definitely not abstract and fluffy; it deals a lot with the code also. DDD
leads us to focus on understanding and to communicate that understanding very well;
in language, in design and in code. You will shift your focus away from designing for a
technology, and you will learn to design for the business domain; to the core of the
problems and solutions. Those are the most interesting parts and what your users
and customers really care about.

about the coursecourse contents / should you attend? / register for the course

Øredev Presentations

My presentations from Oredev are finally available.  After working through almost all the export options on Keynote, I have settled on QuickTime as the distro format.  The “flying code” in the aspects presentation worked out best with QuickTime.  Note that it’s not a continuous playback and you have to click-through each frame.

Factories, Builders and Fluent Interfaces

Last week I started working on very short proof of concept with a team that I am currently coaching at a short term insurance company.  We hit a very common design decision: when do we use a factory pattern and when do we use a builder pattern.
In the problem at hand, we needed to describe an item that will appear in an insurance policy that must be covered for fire damage.  It turns out that these items are not trivial in their structure, and many things influence the premium that will paid by the policy holder for fire insurance.  So, the first bit of code (in Java) in the test looked something like this.

FireItem fireItem = new FireItem();
fireItem.setIndustry("Building Construction");
// the postal/zip code for the location of the insured item
// ignore the number, we actually created a Money class


After the test passed, we refactored and I sneaked in a factory method which will be used to honor default values and at the same time threw in a fluent interface (the term coined by Eric Evans and Martin Fowler.  After all, I was also quietly introducing Domain Driven Design without actually saying that).

The code looked like this.

FireItem fireItem = FireItem.create()
                      .inIndustry("Building Construction")

The FireItem class looked like this:

public class FireItem {
    String industry;
    String occupation;
    // other properties ...

   private FireItem() { }
   public static FireItem create() {
       return new FireItem();
   public FireItem inIndustry(String industry) {
      this.industry = industry;
      return this;
   // other chained methods follow a similar style returning "this" ...

Nice! Much more readable. But, we then realised that it’s easy for someone to miss one of the methods in the chain.  That will result in the item having an incomplete structure.  Not good!  

One of the things I tend to do as a coach, is to let the team I am working with, experience the problem, solution and any rewards and smells as well.  Sometimes I even throw in red herring for sake of experience ;-).  So, the third pass at refactoring was to introduce a validate() method on the item which throws an exception if everything was not in place.

try {
  FireItem fireItem = FireItem.create()
                       .inIndustry("Building Construction")
} catch (FireItemException e) {
  // handle the exception

Now the user of this class needs to know that the validate() method must be called before they really want to use an item object.  Yuck, that’s smelly!  So, for the fourth design refactoring, I introduced a builder and moved the fluent interface to the builder, still using method chaining but introduced a build() method that did the work of the previous validate() method before returning the well structured item.  The FireItem class now needs the traditional bunch of getters and setters (rant – the framework goodies need them anyway!!)

import static insurance.FireItemBuilder.fireItem;
// ...
try {
  FireItem fireItem = fireItem().inIndustry("Building Construction")
} catch (FireItemException e) {
   // handle the exception

Much better!  Note the use of the static import which gives us the liberty to use the static method without specifying the class in code body.  The FireItemBuilder class looked like this.

public class FireItemBuilder {
   private final FireItem fireItem;
   private FireItemBuilder() { 
      fireItem = new FireItem();
   public static FireItemBuilder fireItem() {
       return new FireItemBuilder();
   public FireItemBuilder inIndustry(String industry) {
      return this;
   // other chained methods follow a similar style returning "this" ...
   public FireItem build() throws FireItemBuilderException {
      return fireItem;
   private void validate() throws FireItemBuilderException {
     // do all validations on the fire item itself and throw an exception if something fails

Sure, we can improve the bubbling of the exception from validate() to build() and we could do with a better name for validate().  And perhaps, validate() should be on the FireItem class.  But let’s stick to factories and builders and fluent interfaces.  I think these three things work nicely “together”, when used for the right purpose.

In a nutshell, factories are great for creating objects where defaults and invariants are easily honored during the simple call to the factory.  However, if the structure of the object is more complex which makes long argument lists ugly, and some form of validation is necessary  before we can use an object then a builder works beautifully.

Also, note that the fluent interface was used to improve readability and kick off a tiny little DSL for describing insurance items.

An alternative is to allow the object to have an invalid structure but you track it with an invalid state, perhaps using a state pattern.  This is not exactly what the state pattern was meant for, but it will work nonetheless.

The last time I was with this team was in August 2006, and it is really great to work with them again.  So, much more for me to learn from them.

Looking after your domain model

Mats Helander has written an excellent article on how to manage your domain model with some intelligent design trade-offs.  It’s a lengthy article that even manages to introduce AOP as well.  If you start reading it and wonder where it’s going, just carry on reading…it is written in an evolutionary style.  Nice article, Mats! UPDATE: I have written the Java equivalent of the listing in Mats’ article and attached it.  The AOP part uses SpringFramework 2.5 and AspectJ.  

Patterns at the September SPIN Event

I suspect that many people did not understand what I meant about forces at play and that patterns describe a solution to bring some harmony among the forces in the problem in a particular context.  For the example of the airplane and wanting to serve the right meal to the right person, the challenge is to serve the meal without knowing about the seating arrangement on the plane, and still sequentially access each seat.  Let’s look at how to get rid of the need to know the seating arrangement.
We start with the solution where we need to know the arrangement of seating and number of seats too.  BTW, it’s ruby code.

for row in (0..29) do # 30 rows
    for pos in (0..5) do # seat A-F
       passenger = airplane.seats[row][pos]
       next if passenger.nil?
       passenger.serve_meal("nut free") if passenger.meal() == "nut free"

Of course, if we know the seat number, for example, 15C, then we can do this.  But that does not help at all.

airplane.seats[14][2].serve_meal("nut free") if airplane.seats[14][2].meal() == "nut free"

But, we still expose the data structure of the seats.  So, let’s make it a little better by using the iterator pattern on the data structure for the seats.

airplane.seats.each do |row|
  row.each do | passenger |
    next if passenger.nil?
    passenger.serve_meal("nut free") if passenger.meal() == "nut free"

We could be cuter and do something like this and hide the seats array, but we still expose the numbering scheme of the seating.

airplane.serve_meal("15C", "nut free")

So, we can have the iterator on the seats data structure, which helps a bit.  But we can make it a lot better if we put an iterator on the airplane itself. Now, we just care about occupied seats.

airplane.each_occupied_seat do |passenger|
  passenger.serve_meal("nut free") if passenger.meal()
 == "nut free"

In the airplane class, we have the following.

class airplane
  def each_occupied_seat &block
    @seats.each {|row| row.each { |pos| yield pos if not pos.nil?} }

We are using iterators on the encapsulated seats structure and exposing a new iterator for the airplane. Also, we are only work with seat that has a passenger

So, we started out with a deep need to know the structure, layout and limits of the seating in the airplane. Then we started hiding the data structure for the seats, put iterators on this seats data structure which helped a bit.  But the real breakthrough happened when we started asking the airplane to just give us a way of sequentially accessing each seat that had a passenger.  No more conflicting forces, just a simple harmonious way to access each occupied seat on the plane.  And when the plane seating changes, we don’t care.