Shekhar Gulati is a Java Consultant with over 5 years experience.He is currently working with Xebia India an Agile Software Development company.The postings on this site and on his blog are his own and do not necessarily represent opinion of his employer. His own blog is at and you can follow him on twitter here. Shekhar has posted 25 posts at DZone. View Full User Profile

Domain Object Dependency Injection with Spring

  • submit to reddit

I have always considered domain objects as dumb because they normally don't do anything i.e. they don't have any behavior. But with the advent of Domain Driven Design, the same domain objects have got the power to do useful things. In order to do something useful, they have to collaborate with other classes i.e. they will have dependencies on other classes . The problem is that Domain objects are either created using the new operator or by an ORM framework so as to inject beans into it. For example, we have a User entity and we want to add a behavior like findAllUsersWithSameLastName into the User entity as shown below

public class User implements Serializable {

private String firstname;
private String lastname;

private MyDao myDao;

public List<User> findAllUsersWithSameLastName(){
return myDao.findAllUsersWithLastName(this.lastname);

// setters and getters


Now in order to inject myDao bean inside User entity, we have to mark the User class with @org.springframework.beans.factory.annotation.Configurable annotation which makes the User class eligible for Spring driven configuration. The core idea behind domain object DI is : An AspectJ-woven aspect selects join points corresponding to creation or deserialization of any object matching certain specification. Advice to those join points inject dependencies into the object being created or deserialized.

public class User implements Serializable {

private String firstname;
private String lastname;

private MyDao myDao;

public List<User> findAllUsersWithSameLastName(){
return myDao.findAllUsersWithLastName(this.lastname);

// setters and getters


Just mentioning @Configurable on the User entity does not make this class Spring configured. You need to have org.springframework.aspects-3.0.4.RELEASE.jar in your classpath. This jar contains a class called AnnotationBeanConfigurerAspect which acts on this annotation . AnnotationBeanConfigurerAspect needs to be configured in spring application context xml to obtain a reference to the bean factory that is to be used to configure new objects.  Also, we need to configure the auto scanning of User entity and dao class so that they can be auto-registered. You also need to activate the Spring LoadTimeWeaver which is also present in context namespace.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns=""
xmlns:xsi="" xmlns:aop=""

<context:spring-configured />
<context:component-scan base-package="com.shekhar.di"></context:component-scan>
<context:load-time-weaver aspectj-weaving="on" />


Last thing that you have to configure is to add the javaagent argument to your JVM or eclipse JUnit run configurations


 Lets run the test.

public class UsersTest {

public void shouldConfigureDomainObject() {
User user = new User();
List<User> users = user.findAllUsersWithSameLastName();

 After you run test if you get exception like this

SEVERE: register definition failed
org.aspectj.weaver.BCException: Unable to continue, this version of AspectJ supports classes built with weaver version 3.0 but the class org.springframework.beans.factory.aspectj.AnnotationBeanConfigurerAspect
is version 6.0

then make sure that you have correct version of aspectj jars. If not then please add these dependencies to pom.xml

 This feature is not new in Spring; it existed from 2.0 days but I think it is less known. So next time, you think of adding some behavior to your domain object think about dependency injection in domain objects. Although there is documentation on the web about this, it took some time to make it work. I am also attaching the sample project in case you want to play with it.

di-domain-objects.zip10.38 KB
Article Resources: 
Published at DZone with permission of its author, Shekhar Gulati.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Slava Lo replied on Mon, 2010/11/01 - 4:25am

I can see two issues with this example (maybe not the DDD pattern itself):

1. in order to run search for  'all users with the same last name', there should be some instance of User to call the method. So, in this case it looks like 'chicken or an egg' paradox - how would you get the reference to User on the first place ? (other then creating new instance)


2. Say, you have a list of users with the same last name of about size of 100. Does it mean that there will be overhead of running the aspect-j based injection of dao into each out of 100 instances, while mayby none of them will be used to call that method ?


Mladen Girazovski replied on Mon, 2010/11/01 - 4:51am

This ist not a DDD Pattern, this is the ActiveRecord Pattern, which is quite the opposite of DDD.

DDD advocates the use of a Repository that the User object would access if it needed tosearch for users etc. pp.

Praveen Govindan replied on Mon, 2010/11/01 - 8:48am in response to: Slava Lo

Usually you keep your finder methods static. In the static method you can just do "new User().repository.findxxx()"

Jonathan Fisher replied on Mon, 2010/11/01 - 9:58am

The irony here is your class implements Serializable, but your have specialty logic directly inside your domain object. If the object was passed between two systems, you could not guarantee the specialty logic inside findAllUsersWithSameLastName could be the same across multiple systems...

If you're design isn't distributed (ie not SOA or EJB) there is benefit to having active domain objects, otherwise they can cause chaos in large distributed systems.

Alessandro Santini replied on Mon, 2010/11/01 - 10:35am in response to: Jonathan Fisher

Agree, large distributed application should leverage DTOs, IMO.

Jose Maria Arranz replied on Tue, 2010/11/02 - 6:58am

I agree too


private MyDao myDao;

into a domain model hurts my eyes, fortunately the code of MyDao is not into the domain model :)

I'm sorry, in my opinion this article about the anemic domain model as an anti-pattern is itself an anti-pattern, any experienced developer knows how much crazy is the rich domain model approach (by the way being proposed very much these days).


Igor Laera replied on Tue, 2010/11/02 - 10:57am

I think, the classical Domain Model approach comes from the illusion you can hide everything behind an object and then only communicate over public interfaces with that object. Public interfaces and behaviours that preferably never change ;)

In an agile world, just calling two different methods on an already instanced object can have completely different pre- and post-contracts, not to talk about different transaction-behaviour. Since Java currently  forces the caller to care about exceptions ("throws IOException") but does not to directly ensures any technical or business contract (think: "requires Transaction, requires Instantiation, defines LoginObject, "). This results always in some difference between the intended use and the real use of objects. In large project this gap is part of the nightmare of refactoring huge object trees ("How could this every work without a User and a Product key?")

When I look at big projects right now, I see heavy DTO layers with certain "hot spots"-manager classes (which I find very anti-pattern for different reasons) and then you have (crosscutting) (overlay) use cases combining all that madness into varyingly (un)maintainable code sprinkled with Spring, AOP and everything has to offer ;*)

I would like to have some sort of large object 'magic idiom' to take care about every possible detail, but at the end the classical User().repository.findxxx() always gets its 20 variations with different behaviours - since there is never enough time/willingness/cookie dough to force the next guy to refactor the other five already there. 

For me, this topic moves more and more into how the project (leaders) can enforce a certain style of coding and architectural behaviour. We still have problems to ask hardcore hackers to use Checkstyle, but they should fully get when to do DDD - and when not?


Paul Sydney Orozco replied on Tue, 2010/11/23 - 12:58am

great post. Anyways, i wanna share also a spoon-feed tutorial on Spring MVC

and add step-by-step Hibernate JPA capabilities tutorial to it:


hope it will help people!

Sadsds Dsadsadsa replied on Tue, 2010/12/21 - 4:48am

You've made the classic mistake once you hear that its ok to have behaviour on your domain objects. I would not put the method findAllUsersWithLastName() on the User domain object. It belongs on some other class that perhaps has other query methods such as the UserDao class. As a rule of thumb, if the behaviour acts only on the domain objects attributes, then I would add it to the domain object. I would consider a domain object with a lot of other non-domain dependencies (such as persitance services) a bad design. I've found creating domain object using a repository class very useful as it means the client code is not required to use 'new'. The repository class can have services injected into it.

Rogerio Liesenfeld replied on Tue, 2010/12/21 - 1:13pm

A method like "findAllUsersWithSameLastName" does not belong in the User class, but other methods in a domain class might very well need to access the database. In a past project, I used to create such methods for "derived" attributes or associations (implemented in getters), which themselves were not persistent but were computed from other persistent entities.

My solution was to use a static persistence facade on top of an ORM API, rather than DAO or Repository objects. So, I could write such a method as simply as the following, where the facade methods are statically imported:

    public int getSomeComputedAttribute()
        Integer result = findSingleResult("select count(*) from Xyz x where", abc);
        return result;

It works really well, with no need for DI.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.