Comments on: The power of immutability in a Rich Domain Model

By: Jalal

Jalal — Tue, 09 Nov 2010 12:22:04 +0000

Now, with new versions of hibernate you can use final fields and private default constructors, consequently, in private default constructor final fields can be set to null or any arbitrary default. because constructor is private, no ordinary code can call it, just hibernate.
After calling private default constructor by hibernate , hibernate will directly set final fields from Data source. data source already contains valid data and thus entity created by hibernate is already valid.
hibernate ability to set final variables, calling private constructors, and directly accessing field. are good features which enables rich domain model.

By: Rikard

Rikard — Sat, 27 Mar 2010 21:46:13 +0000

Well i have hibernate in my domain model. But im shifting to remove hibernate in the future. It breaks the domain model, even if i have the annotations on the field level. Besides letting hibernate inject and clutter the entities with freamwork specific annotations well annotations is a dependency in disguise! I can rabble on why not to use Hibernate (and annotations)in a big size application but that is another post

But this post gives a very good understanding about the power of domain models and aggregates and hey immutibility is the way to go for in all code

By: Allard

Allard — Tue, 02 Jun 2009 19:41:42 +0000

I just did a little quick research. Hibernate doesn’t have any trouble changing the value of a final field. In fact, you can just make persisted fields final and set them to null or 0 in the default constructor.
However, I have no idea what this does to the multi-threading guarantees that final field provide. Typically, these objects are only “shared” among thread after they have been fully constructed and initialized by Hibernate.

By: RichB

RichB — Tue, 19 May 2009 16:23:58 +0000

I have an existing immutable domain model (immutable for a highly concurrent problem). I’m replacing the data layer with Hibernate (NHibernate) actually and have the same problem as you. As far as I can see my options, they are: treat Hibernate as the Data Access layer and load my existing immutable domain model from the Hibernate entities (treating Hibernate as the Data Access layer). Alternatively (and related), make my immutable domain model “wrap” the Hibernate entities, making them immutable.

By: Allard

Allard — Sun, 17 May 2009 08:35:03 +0000

Zoran,

thanks for your pointers. The problem I encountered (and I always use the field access method) is that Hibernate needs a no-argument constructor. I’ll try to see if I can initialize the final fields to some default values (0 or null) and see if hibernate can change the values even though the fields are final.

By: Zoran

Zoran — Sat, 16 May 2009 22:18:45 +0000

It is well worth to note that Hibernate (and possibly other ORM frameworks) do in fact work with immutable objects, but you have to set the access method to ‘field’. You may be wondering how can this help if your fields are final, well, since Java 1.5 they are not really final, checkout http://www.javaspecialists.eu/archive/Issue096.html .

By: Ben

Ben — Sun, 12 Apr 2009 22:00:24 +0000

Allard,

Excellent post (as usual). It’s good to see good people paying attention to proper domain modeling again — perhaps we can start to get away from people being “Java” developers or “Ruby” developers or “Popular flavor of the day” developers and back to being software engineers for whom the exact implementation platform is a secondary concern.

You are correct as well about the important role immutability can and should play in design. Not because immutability is a “cool” idea or a “best practice” (i.e. the consulting reason for doing things). But because, as your example shows, sometimes things simply shouldn’t change anymore. It is sometimes possible for an object to reach a terminal state after some time and in that case developers shouldn’t be so afraid to incorporate that fact into their software design.

It is indeed a pity that frameworks like Hibernate and JPA don’t offer direct support for value objects or (semi-)immutable objects. This is, of course, the drawback of the fundamental choice such frameworks make to base themselves on JavaBeans (even if they call themselves POJO frameworks). As dlemoing points out, you can get part of the way in Hibernate (use a CompositeUserType implementation to persist or recreate your immutable object). Unfortunately that means having to embed the immutable object in a dedicated container object that is then itself a JavaBean. You can hide that detail within your repository implementation (to use Evans’ terminology), but it’s an awful lot of work.

In any case, good stuff once again. Keep it coming!

By: Allard

Allard — Tue, 07 Apr 2009 15:03:16 +0000

Hi dlemoing,

Thanks for you remark and links to Evans’ pages. Perhaps in Evan’s terms the OrderLine would be called a ValueObject, since it is fully immutable.

However, you can imagine a state field on a line item to indicate the processing state of that item. In that case, part of the entity is immutable, the other part isn’t.

My key point is that immutability is, in my opinion, often overlooked as an option to reach certain goals.

By: Ravi

Ravi — Tue, 07 Apr 2009 12:58:32 +0000

Sorry did not read the conclusion

By: Ravi

Ravi — Tue, 07 Apr 2009 12:58:01 +0000

Nice article. Will hibernate work with a immutable rich domain model ?