June 15, 2006

session 7: practical Rich Domain Models

this presentation started out quite good, but the longer it went on, the less I suspect that the presenter has implemented many real RDM apps)

  • Anemic domain == not cost–effective; no competitive advantage
  • Rich Domain: Persistence is a secondary concern
  • challenges: Use RDM in a 3–tier architecture; leverage existing domain modelling skills; capture domain expertise
  • goals: Manage complexity of domain and of software; improve test strategies; make refactoring possible
  • prerequisites: Compexity – not worth it for a 2–month project. Investment + skills; committed team; compatible process; access to domain experts (I am not sure I buy this; most of these are sucess factors for any projects but none of them are essential)
  • separation of concerns (layered architecture): importance is appreciated but is not well understood in the field (is it possible to have SoC without a layered architecture? I think maybe)
  • You can't managed complexity with design patterns alone.
  • Encapsulation is fundamental. Getters, and especially setters are eeeviilll. Enforce class invariants; don't expose internal state.
  • Immutable classes: instead of changing object state, create a new object with the changed state and return that. (n.b. that private fields are accessible from other instances of the same class). Good example: java.lang.String – methods on it all return a new string. Dramatically reduces the complexity of large, modular applications, though it's probably overkill on simpler apps
  • Entity classes are generally mutable (often a requirement of the persistence technology) , though you can use immutable classes and use the EntityManager / Session merge() method to reconcile changes. This doesn't work with immutable items in immutable collections though
  • Aggregate objects: Don't expose the aggregation, and don't be mutable.
  • Rich domain models are very testable – easy to mock and amenable to TFD
  • Don't let your tests be longer than 15 lines (!)
  • lessons learned: ORM – tools will impact the deisgn (availability of immutable entity semantics). Always use field access; Avoid LazyInitialisationException (OSIV is not the answer – alternatives include AJAX*, use fetch joins; use eager loading)
    lessons learned – MVC – binding generally requires untyped setters (though spring binding + propertyEditors will avoid that)

* that's a stupid recommendation; each ajax call will increase the latency of your application: L~N(ajax–calls)

- 6 comments by 1 or more people Not publicly viewable

[Skip to the latest comment]
  1. Chris May

    [Comment added on behalf of Erik van Oosten at http://day-to-day-stuff.blogspot.com because blogbuilder won't allow him to enter his URL in a comment :-) ]

    using AJAX for this is not a complete stupid idea. Of course you would not use this for a page that has just been sent to the browser. By the way, I vaguely remember that the presenter said something like you should only use this when you do not need to display the data often.

    18 Jun 2006, 22:31

  2. Chris May

    Maybe I've just mis–understood the presenter then. But my take on it was that he was suggesting that a good alternative to using OSIV to allow you to traverse a relationship in the view was to use an AJAX call while the view's rendering. I would absolutely agree that, in the case where you're not initially going to display the extra data, this is a good idea (several of our apps make use of exactly this technique), but I don't really see that that's got much to do with avoiding OSIV / LazyInitEx – it's just general performance optimisation.

    The way I understood it was that he was suggesting that one might write a page which rendered and immediately used AJAX in it's onload to complete rendering the page, (kind of like the current crop of 'ajax portals' like google/ig ). That's what I think is poor advice, because if you care at all about time–to–render for the end user, you're going to make things worse and not better for them.

    18 Jun 2006, 22:39

  3. Steven Devijver


    Thanks for this excellent overview of many SpringOne sessions, I think they are good summaries. Here are some points/counter–points regarding my session on rich domain models:

    • I did work on multiple RDM projects. I think a 1 hour session is just not enough time to cover the practical side of the many topics in much detail.

    • About the prerequisites: every single one of them are essential to manage the complexity of large applications successfully, I want to be absolutely clear on that :–)

    • Regarding the use of AJAX to avoid LazyInitializationException: it's an option I've used before for data that most often will not be shown. In other cases fetch joins are a better solution together with eager loading, depending on the situation.

    As I mentioned at the start of the session, and as you also mention: much of what I've talked about is only applicable to complex applications. Typically, you will find that in such applications some part use specific rich domain models while other parts may be oriented towards CRUD operations. It's all about isolating complexity and reducing the risks which is only required when there actually is complexity and risk involved in the first place.

    Btw, the slides for most sessions (including the "Practical Rich Domain Models" slides) are available on the SpringOne site:

    link (downloading slides requires signup/login)

    30 Jun 2006, 11:48

  4. Chris May

    hi Steven, thanks for dropping by, and thanks for the link to the slides.

    I think your comment

    About the prerequisites: every single one of them are essential to manage the complexity of large applications

    is interesting; I'd like to pick at it a bit. All of those attributes that you've listed as 'essential' are not binary. Take 'Investment', for instance – no project ever has unlimited funds at it's disposal, so if you're going to suggest that investment is essential then you need to qualify how much. 'Enough' isn't really an answer, because different stakeholders will have different ideas about how much is enough.

    Similarly for a 'committed team' – how committed, exactly, do you mean? "Would gladly lay down their lives for the project", or "Would come in to work at least 4 days a week, and not take more than 2 hours for lunch" :–)

    That's why I don't think you can describe these attributes as 'essential'. It's a bit like saying in a requirements document 'it is essential that the web server is high–performance' – it makes no sense unless you can quantify it. All of these qualities are desireable, and they're all success factors – the more of any of them that you have, the more likely you are to succeed. If the project fails, you'll probably be able to find one of them and tell management that it's because you didn't have enough of it that you failed. But that's not the same as being 'essential'

    30 Jun 2006, 13:05

  5. Steven Devijver

    Hey Chris,

    Fair enough. I've touched on these subjects during my session so there's more to it then just some words in a bullet list.

    On the topic of investment, my point is that you need a sufficiently large budget to start with. If you only have a budget for 2 months of development, trying to create a rich domain model will probably slow down the progress compared to an anemic model (although the project duration is not the only factor in the cost equation). I made this point because I can image people wanting to try RDMs on small projects and finding out it doesn't work for them. On projects with a big budget (say 1 year +) you can use the available time to improve the domain models to a level where they actually become useful and to spread the risk of project failure over several modules rather than one big application that uses one domain model.

    About commitment in the development team, I'm not talking about the will to endure great amounts of stress and dispair. What I've mentioned during my session is that the entire developement team has to be committed to creating rich domain models for the application. You'll find that if there's no consensus in the team on the usefulness of RDMs it's probably better to find a common ground rather than to push RDMs down everyone's throat.

    30 Jun 2006, 14:52

  6. vsoso@vsoso.cn


    09 Nov 2007, 09:30

Add a comment

You are not allowed to comment on this entry as it has restricted commenting permissions.

Most recent entries


Search this blog

on twitter...


    Not signed in
    Sign in

    Powered by BlogBuilder
    © MMXXI