To DDD or not to DDD

Imagine the application you're currently working on. Imagine your users were happy with a primitive text based UI in a console, and imagine persistence was not an issue because you have an obscene amount of RAM (a billion terrabyte) and your server never crashes (so no DBMS needed).

Would there be any complexity left to deal with in your software? If the answer is no, you're lucky (in a way). If the answer to this highly hypothetical question is still yes, then domain driven design (DDD) might be the thing for you.

Subclasses with ActiveHibernate

Finally I resumed my work on ActiveHibernate. It now uses a XmlMarkup Builder and the visitor pattern to sort out the relationships between different persistent classes and to generate the mapping XML internally. This might sound like overkill, but even to get inheritance up and running it seemed like the only way to keep things maintainable. Anyway, the Ruby code

class Payment
  include Hibernate
  hattr_accessor :amount,:double
  ...
end

class CreditCardPayment < Payment
  join_with_table do
    hattr_accessor :creditCardType,:string
    ...
  end
end

class ChequePayment < Payment
  hattr_accessor :chequeNumber,:string
  ..
end

generates the mapping

<class name="Payment" table="PAYMENT">
  <id name="id" type="long" column="PAYMENT_ID">
      <generator class="native"/>
  </id>
  <discriminator column="PAYMENT_TYPE" type="string"/>
  <property name="amount" type="double"/>
  ...
  <subclass name="CreditCardPayment" >
      <join table="CREDIT_CARD_PAYMENT">
          <key column="PAYMENT_ID"/>
          <property name="creditCardType" type="string" />
          ...
      </join>
  </subclass>
  <subclass name="ChequePayment" >
          <property name="chequeNumber" type="string" />
          ...
  </subclass>
</class>

The <join/> construct in the CreditCardPayment mapping allows to combine the table-per-class-hierarchy and the table-per-subclass mapping strategies in one inheritance hierarchy. In the Ruby mapping DSL it can be nicely expressed with a class method (table name and key are optional arguments) and a block. The fact that a Ruby class definition is just ordinary Ruby code (with self referring to a Class object) opens a whole new world to the simple Java developer that I am.

In Subversion soon.

Deep Cloning an Object Graph in .NET

The other day I was looking at the really nice NHibernate mapping examples by Davy Brion. His entity base class looks like this:

public abstract class Entity
{
   private long _id = -1;

   public virtual long Id
   {
      get { return _id; }
   }

   public virtual T Clone()
   {
      MemoryStream memoryStream = new MemoryStream();
      BinaryFormatter binaryFormatter = new BinaryFormatter();
      binaryFormatter.Serialize(memoryStream, this);
      memoryStream.Position = 0;
      return (T)binaryFormatter.Deserialize(memoryStream);
   }
}

It is used like so:

public class Order : Entity<Order>
{
   //...
}

The Order class derives from a template class that uses the Order class itself as parameter. I had never seen this before, and, for example, it gives all your entities a Clone() method that returns the proper type.

What's even more interesting is the way the Clone() method has been implemented by just serializing to a memory stream, immediately followed by a deserialization. It gives you a deep clone of your entity, together with all child entities it references. This technique is robust, simple, clean and generic (requiring no extra development effort).

I can imagine some people will object to this because of performance, but that only makes me think of all the crimes that are committed daily in the name of performance and (premature) optimization.