DDD Without any ORM tool, is it possible !!

DDD Without any ORM tool, is it possible !!

When reading DDD book and trying out it on a sample project that doesn’t use any ORM tool. I came across a question, is it possible to strictly implement DDD without any ORM tool !

Is there any one here who has implemented DDD on any real project that doesn’t use any ORM but pure JDBC only?

Before few days, I had a question on how to paginate and lazy load non root objects http://tech.groups.yahoo.com/group/domaindrivendesign/message/15925

Various alternatives and answers came up, but why do I need to find an alternative ! I don’t need to do any thing specific when using hibernate and just depend on the lazy loading support provided by it.

I want to paginate because I don’t want to load entire graph of few thousand objects into memory and when using hibernate and lazy loading that’s not an issue. With NO-ORM, I can achieve similar thing by hand coding dynamic proxies for lazy loading, and let repositories handle it.

However the second point is more important.

The second question is related to repositories, transitive persistence and dirty checking.
The DDD book (Chapter 6 – repositories) says “it allows freely switching persistence strategies at any time.”

Is it really possible and easy without modifying domain at all !

How about dirty checking and persistence by reachability without any ORM ?
When you save/update an aggregate root, entire graph should be saved and/or updated. How the repository will determine which objects are modified/inserted or deleted?

Probably you will need some thing like isNew() isStale() inside every entities to find out if it needs to be included as part of insert/update. And set flags when ever any setter or any other method changes state of the object. I have seen similar thing in a project which uses DDD with JDBC.

Several answers came up

Get the data from the database and determine updates, deletes, and inserts in code.

This may not be the best routine, but I use a boolean flag to determine what needs persisted. I have a property in each entity called .IsDirty. When anything inside the aggregate root needs persisted, I use the root’s repository and call root.Persist and I go through the root. The root repository then loops through each entity and tests the .IsDirty flag

Do you see any pattern in this answers ?

  • It says either modify your domain model or write some thing like your little ORM to do this things.
  • That says DDD is tightly bound to ORM and “Freely switching of persistence technology” means switching from one ORM to another (it could be your own).

How about Delete?
Lets say root has a collection of associated entities (In my example MessageFolder has Collection of messages)

I can do some thing like
MessageFolder.remove(Message message)

That would remove message from the collection. When saving the MessageFolder, how the repository can find out what messages are deleted? Either message folder need to maintain a collection of removed messages or repository need to have old message folder for comparision. The first option forces me to modify MessageFolder, that mean domain model became aware of underlying persistence technology. The second option would need to load old entity which would affect performance.

It might be possible to switch to ORM from a No-ORM application but what about switching to NO-ORM from ORM ! Does that mean I will have to add custom behavior to my entities to figure out weather they are new or modified or deleted.

These are few questions that I am not able to answer my self and seeking some expert thoughts. If you have done DDD for a real life project that does not use any ORM, please comment.

Some people said CQRS and Domain events can solve this problem, however I am yet to find a working example.

There is a sample DDD application created by DDD community. The sample application uses Hibernate in persistence layer.
I wish some day DDD community would release a sample application that works on pure JDBC. As still there are lots of companies who use bare JDBC and no ORM at all.

Look at the thread http://tech.groups.yahoo.com/group/domaindrivendesign/message/16021

Leave a comment


  1. Reedo

     /  May 25, 2010

    I don’t see any flaws in your understanding. DDD domain objects should only implement the data model, not persistence. So external code must store the domain objects. So the external storage code must know how to map the domain objects to the storage device (it might be a relational database engine, a file, an object-oriented database, a POST to “cloud” storage like Amazon S3…) . When the storage device is a relational database, the code must object-to-relational-map (ORM). The map could be through Hibernate, iBatis, hand-written JDBC, or any other tool or technique.

    To store a pure & separate domain layer in a relational database, an ORM “strategy” is necessary but the strategy might not be a “tool”.

    • snimavat

       /  June 2, 2010


      Yes, I understand that.

      But the question still remains open, ‘DDD Without any ORM tool, is it possible’

      Weather it is hand coded ORM tool or hibernate/JPA, doesn’t matter.

      Is it possible to do DDD with JDBC, and not being forced to build your little ORM over JDBC !

  2. Reedo

     /  May 25, 2010

    I have written my own persistence layer, but it was years ago before I read about DDD. The repository object (it wasn’t called a “repository” but a “DAOFactory” or something like that) kept a list of domain objects that had been asked for. For each object it stored the originally retrieved object (with all the original member values) and passed a copy as an interface type that didn’t include all the object’s getters/setters. At the end of processing, the application code would call a method on the “repository”, and it would iterate over the list of objects looking for which ones had changed, and then update the database. (The repository also had some “read-only” retrieval methods in which the repository skipped the copies and update checks.) Later I switched to having the persistence code call database stored procedures that checked a “timestamp” table column to ensure better consistency without requiring transactions. By the end, it was a bit like Hibernate but with less flexibility and fewer features.

  3. ali

     /  May 23, 2013

    sorry i mean “Have you found any non ORM solution for DDD without poluting entities with database logic?”

    • snimavat

       /  May 24, 2013

      No, I am yet to find a real life project which uses NO-ORM

  4. i struggled with the same question. And totally agree with you. Eıther you should write a small orm(just special to your domain) or use an orm. If i choose first, then sometimes should pay the price with performance since my orm layer could not do dirty checking and other stuff or i should reflect read/write path to my code(or define relations with repositories) which make my code look like a transaction script.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: