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"
    end
end

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"
  end
end

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"
end

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?} }
  end
end

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.

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.

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 course /  course 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 course /  course contents / should you attend? / register for the course

• Solving Domain Problems with Aspects has a couple of slides with repeated transitions (courtesy of the export ).  This one has the flying code, as Claudio Perrone calls it!  And it is the presentation that lead to the chat with Ayende Rahien.  He has done something similar in C# here. - 29.1MB @ http://aslamkhan.net/wp-content/uploads/2008/11/SolvingDomainProblemsWithAspects.mov

• Managing Diversity in Agile Teams was inspired by Claudio’s presentation style.  Highly visual with minimal text.  It’s about story telling, movie script style and not about bullet point presentations.  Thanks, Claudio! - 16.6MB @ http://aslamkhan.net/wp-content/uploads/2008/11/ManagingDiversityInAgileTeams.mov

• Bootstrapping your SOA Project has the slides for the workshop that I ran.  It’s a mixture of traditional and visual.  The traditional is used purely for reference / take-home material. - 13.5MB @ http://aslamkhan.net/wp-content/uploads/2008/11/BootstrappingYourSOAProject.mov

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");
fireItem.setOccupationCode("Workshop");
// the postal/zip code for the location of the insured item
fireItem.setAreaCode(7800);
// ignore the number, we actually created a Money class
fireItem.setSumInsured(200000.00);
fireItem.setRoofing("Non-Standard");

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")
                            .withOccupation("Workshop")
                            .InAreaWithPostalCode(7800)
                            .forSumInsured(200000.00)
                            .havingRoofing("Non-Standard");

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")
                              .withOccupation("Workshop")
                              .InAreaWithPostalCode(7800)
                              .forSumInsured(200000.00)
                              .havingRoofing("Non-Standard")
                              .validate();
} 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")
                                .withOccupation("Workshop")
                                .InAreaWithPostalCode(7800)
                                .forSumInsured(200000)
                                .havingRoofing("Non-Standard")
                                .build();
} 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) {
      fireItem.setIndustry(industry);
      return this;
   }
   // other chained methods follow a similar style returning "this" ...
   public FireItem build() throws FireItemBuilderException {
      validate();
      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.