none
Pondering the differences between DDD vs. ActiveRecord

    Question

  • I am looking at the differences between an ActiveRecord approach and DDD.  I am curious as to the strengths/weakness between the two approaches.  Any thoughts are welcome.
    Wednesday, June 27, 2007 8:06 PM

Answers

  •  

    Congratulations - your post has been selected for an ARCast.TV Rapid Response!

     

    To listen to Architect MVP Jefferey Palermo and Ron Jacobs address your question click here

     

    Hope this helps,

     

    Ron Jacobs

    Friday, June 29, 2007 2:36 PM
  • In order to avoid comparing apples and oranges, the question should be about the difference between the Active Record pattern and the Domain Model pattern (link) [http://udidahan.weblogs.us/2007/04/21/domain-model-pattern/].

     

    One of the primary differences with the Domain Model is that you can unit test easily it without any connection to the DB. With Active Record, you'd need to mock out each objects connection to the DB, as well as set up the appropriate interaction behavior for that mock.

     

    Domain Model classes have no code that deals with persistence. This is not to say that the design of these classes isn't influenced by persistence and performance considerations - for instance, is there an Orders collection on the Customer object, or do we define a separate query object for getting orders for a customer?

     

    Martin Fowler, who wrote the book on these patterns sums it up this way: Active Record pattern is suitable for smaller, simpler domains whereas the Domain Model pattern supports more complex, larger domains.

     

    Does that help?

    Saturday, July 7, 2007 11:14 AM

All replies

  • ActiveRecord mixes the infrastructure concerns with the model by letting every aggregate handling it's own data access while DDD separates thoose concenrs.

     

    Example - ActiveRecord:

     

    order.Save();

    order.Update();

    IList<Order> top10Orders = Order.GetTop10Orders();

     

    Example - DDD

     

    orderRepository.Save(order);

    orderRepository.Update(order);

    IList<Order> top10Orders = orderRepository.GetTop10Orders();

     

     

    The difference might seem subtle but is actually a difference in fundamental philosohpy. DDD is separating the conecerns, where the domain should stand alone from the infrastructure (like the database and DB access logic) and the communication with the persistance store should be done through a designated class, activerecord don't.

     

    I don't like to use ActiveRecord for larger projects simply because the repositories in DDD gives me the ability to have focused small classes that do their job.

     

    That said, most of the practices in DDD can be applied to a domain utilizing ActiveRecord as well. The data access strategy in DDD is just a minor concern, just that it breaks some of the fundamental principles of DDD to mix the concerns.

    Thursday, June 28, 2007 7:01 AM
  •  

    Congratulations - your post has been selected for an ARCast.TV Rapid Response!

     

    To listen to Architect MVP Jefferey Palermo and Ron Jacobs address your question click here

     

    Hope this helps,

     

    Ron Jacobs

    Friday, June 29, 2007 2:36 PM
  • This is a really cool initiative Smile

     

    Although after I've listened to the response I wonder a bit on one of the comments you made Ron. You said that "It looks like Domain Driven Design is about factoring this kind of data access into it's own sort of repository classes". Did you mean DDD as a whole or DDD in the context of the original question?

    Friday, June 29, 2007 2:50 PM
  • I meant DDD as a whole - but I'm new to this so tell me if I'm wrong :-)
    Friday, June 29, 2007 9:59 PM
  • Well you are correct in that DDD stipulates that data access should be a separate concern (where repositories is the pattern used), but that is just a little piece of what DDD actually is and a side effect of the ground principles of DDD.

     

    Jeffrey is on the spot when he in the beginning of the cast introduces DDD as a philosophy. Eric (and Jimmy) often talks about DDD as being a set of principles for writing software which includes practices from how to effectively involve "domain experts" (bussiness experts) into the software project and alot about different practices to make the software express the intent of the bussiness. They also talk about different OO patterns to solve common problems when building bussiness software. A lot of DDD is based on agile values and object orientation, but there is a strong connection to adding buissiness value and letting the bussiness be a strong factor and influencer when building the actual software.

     

    Eric was on DNR a couple of weeks ago: http://www.dotnetrocks.com/default.aspx?showNum=236 where he sums up the basic ideas around DDD.

     

    If you haven't read any of Jimmys or Erics books yet you really should. They changed the way I look at software =) (well actually all the dicsussion with Jimmy about the books did that, but still Wink

    Sunday, July 1, 2007 2:53 PM
  • Being in the middle of a maintanence project of an ActiveRecord style application, I can point out a few things I don't like about ActiveRecord.

     

    Order order = new Order();

    order.Load(123);

     

    1) how do you cache basic read-only stuff?  An alternative would be to use a static method Order order = Order.Load(123);

    2) What exactly is Load() retrieving? LineItems? the Customer?  I guess you could expose LoadDeep() and Load(), but that doesn't really address the issue.  You will run into problems where in scenario A, Load() should get LineItems only.  In scenario B, Load() should get LineItems and Customer.

    3) If Load() retrieves lineitems, does it call LineItem.Load()?  Does that retrieve the product?

    4) What if down the road I need to use a subclass of Order?

    5) If I decide I need to handle heavy reading/writing to xml, what does that look like? LoadXml()?  Do you really want all that hanging off 1 class?

     

    In general, I prefer to separate A) the basic logic of the entity B) the construction knowledge of the entity from persisted values C) The actual retrieving of entity values from persistance

     

    Those are the 3 biggest things I dislike about ActiveRecord style persistance mechanisms.

    Wednesday, July 4, 2007 7:04 PM
  • ActiveRecord also promotes tight coupling.  Tight coupling is a Bad Thing.
    Thursday, July 5, 2007 5:41 PM
  • In order to avoid comparing apples and oranges, the question should be about the difference between the Active Record pattern and the Domain Model pattern (link) [http://udidahan.weblogs.us/2007/04/21/domain-model-pattern/].

     

    One of the primary differences with the Domain Model is that you can unit test easily it without any connection to the DB. With Active Record, you'd need to mock out each objects connection to the DB, as well as set up the appropriate interaction behavior for that mock.

     

    Domain Model classes have no code that deals with persistence. This is not to say that the design of these classes isn't influenced by persistence and performance considerations - for instance, is there an Orders collection on the Customer object, or do we define a separate query object for getting orders for a customer?

     

    Martin Fowler, who wrote the book on these patterns sums it up this way: Active Record pattern is suitable for smaller, simpler domains whereas the Domain Model pattern supports more complex, larger domains.

     

    Does that help?

    Saturday, July 7, 2007 11:14 AM
  • Hi,

    Nice response.
    I have a question about DDD now :

    In a DDD, what kind of code would be in the "Order" class since it has no persistance related methods ? I've worked on projects that are supposed to be DDDed and the only code that was in those "business classes" was fields and getter/setters so I really can't see any usefull code to put there.


    Wednesday, August 20, 2008 4:40 PM
  • I have created a hybrid of DDD and Active Record in my framework. Accordingly, there will be an Order entity and OrderCollection. Individual entities will have Load/Save/Delete methods. e.g. Order.Load(orderID). Multiple Orders will be handled by OrderCollection. e.g. OrderCollection.LoadOrdersByCustomerID(customerID), OrderCollection.Save() etc.

     

    In-order to hide the CRUD operations of the entities from the consumer, the CRUD methods can be made internal to the domain layer and a Service can be exposed in-order to interact with these methods. By doing so, we don't need to create maintain multiple classes for a single entity.

    Monday, September 1, 2008 3:01 PM
  • Hi Ajil,

         Your approach is good.  It is similar to msdn.microsoft.com/stocktrader entities, where you have a basic domain entities and also service entities.

     

    Thanks,

    { Gaja; }

     

    Thursday, September 4, 2008 1:35 AM
  • Not that I'm arguing that your implementation is good or bad, but ultimately, it is another variation of the Active Record pattern.  Anytime you see persistence methods on "entity" classes, you are looking at Active Record.  That's the definition of the pattern.

    DDD by itself is not a pattern, but closer to a pattern language or methodology.  It's persistance mechanism is primarily done through the Repository pattern, which looks quite a bit different in implementation from an Active Record implementation.

    Again, I'm not arguing whether your implementation is good or bad.  I'm only pointing out the differences in the patterns.
    Thursday, September 4, 2008 1:25 PM

  • I think ActiveRecord is great.  For larger modles maybe DDD is ok, but I like the fact that I can call methods off a single object.  I think it's very benefecial to have this.  So, to keep it short, i'm a fan of ActiveRecord (nothing against DDD/Repository) and use it quite often.  Especially for websites using tools such as Subsonic.  Great stuff. 

    For the person who was worried about Load() vs LoadDeep() - there is something called lazy loading associated with ActiveRecord and it's quite nice.  If you've ever worked with an OODBMS this maybe a familiar concept.  

    I think the answer depends on the project at hand.  Active record follows a methodology called KISS (keep it simple stupid) that I like to develop in.  I don't use overkill when designing projects that don't need anything other than simplicity. So, ActiveRecord IS good, DOES have it's place and IS used all the time in designs.

    Don't let theory nazi's sway you from a decent tool such as ActiveRecord - unless your projects calls for DDD.
    Friday, November 21, 2008 11:47 PM