Meeraj Kunnumpurath's Blog

Rich Domain Model and Transparent Persistence

I have worked on quite a few enterprise systems built on the J2EE platform in the past few years (some in which I was actively involved in the design and some I worked on other people's design). I have always felt there was something not quite right in almost all of those systems. No matter however hard we tried, we ended up with systems that were not seamlessly object oriented across the various application layers. An evident after effect of this was there were often redundant code and logic duplicated in the various application layers. One obvious example was the myriad of transfer objects that mimicked the underlying entities in terms of state. This caused a huge amount of coupling right from the database through the business layer to the user interface.

I used to think this was an inevitable by-product of distributed systems where it was not such a good idea to transport state and behaviour. However, I soon realised in most but not all of the systems, this was caused by the over-emphasis on use case analysis without significant attention to proper domain modelling. The system was seen as a black box monolith that accepted user requests and produced responses. This led to the design of a bunch of stateless services exchanging dump data between the invoker and the invoked. As a result, domain logic was often duplicated in the various application layers.

Couple of weeks ago, I started on this new project and have had the fortune to work with Rod Johnson (I always wanted to work with him since the first time I met him in a restaurant in Brick Lane three years ago). This project has brought a breath of fresh air into my experience with J2EE. Here we no longer think in terms of dump transfer objects and entity beans. Here we no longer have use cases as the sole design artefact. More than everything, we have a rich reusable domain model built using object-oriented paradigms like inheritance, composition, polymorphism and re-entrancy. And even more important the persistence of the domain layer is transparent using Hibernate. Our object layer doesn't remotely resemble the data layer. I am hugely impressed with Hibernate's persistence capabilities (though there is scope for improvement as any other software; I had some difficulty mapping polymorphic collections).

I think with a proper attach/detach strategy, and transparent data versioning you could have a rich domain layer that can be seamlessly reused in the distributed process spaces of your application. After reading the early draft of EJB 3.0, I understand most of these stuff will be supported by entity EJBs. Anyway, it is a long way to go before the spec becomes final and vendors start supporting it. For the time being, we have some fantastic commercial and open source O/R mappers and JDO implementations, that will move us forward from the "old-school" J2EE of transfer objects and entity beans towards rich domain model and transparent persistence.

Comments

• OO eventually One could say it is an inherent feature of most of the J2EE technologies that they encourage service based patterns. Read 'procedural' for service. Maybe this is part of the slow evolution towards OO that we thought was over many years ago, maybe it will take a whole generation of new programmers to switch the inherent tendency towards procedural thinking. It is good to see the development of more and more containers and frameworks which do not work against the OO paradigm but support it. In a very practical way as Meeraj has highlighted it avoids the replication of domain information in many places within the application. After all shouldn't we to the best of our ability say something once and once only in the system in case we contradict ourselves? PS: You're blog says you work for EDS, you should probably get that changed.

  Posted by: neilellis on July 20, 2004 at 08:02 PM

• OO now! You are right, there are a lot of interesting frameworks available now, which can give you seamless object-oriented transparency across the enterprise, and even the Internet. One of them is a free software project I host here at java.net, it's called the cajo project. It is very small, simple, and flexible. It does not rely on J2EE or EJB, in fact it runs very well on J2ME, so you can even link in PDAs! It's designed in such a way that you don't build your code to its model, but rather you add its capability to your esisting designs, without restructuring them. It's rather unique in that regard. I welcome you to come have a look. I think you'd like it a lot. It sounds to me like it could be just what you're looking for. Highest regards, John

  Posted by: cajo on July 20, 2004 at 09:07 PM

• OO now! Oh darn. Another good looking framework to understand. Thanks though John I will certainly take a look at this project. Regards Neil

  Posted by: neilellis on July 21, 2004 at 01:17 AM

• modeling time If your db is fairly static and controlled by another department, then I guess it could have sense to have an object oriented model of your data and a mapping w/ hibernate. But if your db changes, if you designed the schema, why is it good that your OO model is totally diferent from your relational one? Does that mean that your design goes like this: 1. design db using relational techniques 2. design OO clases for your app using OO techniques 3. write your app 4. write your mappings Why is this better than: (approach 1) 1. design your db using relational techniques 2. design the procedures for those tables in Java using procedural techniques Or alternatively, (approach 2) 1. design your app using OO techniques 2. persist using OO techniques (Prevalayer, OO db) Approach 1 is necessary if for political or whatever reason relational rules in your company, or you absolutely need a relational db. Since you are already tied to a db, db's are all you do, and don't care about nonconventional data sources (like XML, etc..), then why not just make your objects contain the procedures that operate on the data inside your db. Why not have NO OO model of the business and just model commands (Command Pattern) in a reusable fashion (composition of commands, etc..)? I don't blame EJB for being a bit procedural.. I blame it for having the pretension of OO and the unnecessary overhead of value objects, etc.. (if your app needs to be highly scalable this is useful, but as a lot of PHPers will tell you, this is often not the case unless you are eBay). Approach 2 .. if you are not tied to relational dbs, and want to model in OO.. then why even bother with the relational model.. just persist all the objects a la Prevalayer or serialization or XML. Forget the relational model entirely. O/R mapping is useful if you absolutely have to have 2 models of your problem. But can't you often get rid of one of them in many non-large scale enterprise integration systems?

  Posted by: dog on July 22, 2004 at 07:57 AM

This work is licensed under a Creative Commons License.