Tuesday, September 26, 2006

Spring, DDD and AspectJ - An Example

In my last post, I discussed the possibilty of using AspectJ with Spring to inject domain objects with service objects to create a richer domain model. This follow up is to explore some example code based on a Customer -> Account example given by Ramnivas.

In this example, we are trying to get the net worth of a Customer object. A Customer object has a relationship with an Account object, but it only has a reference to the Account object's id:

public class Customer {
    private Long accountId;

    public Long getAccountId() {
        return accountId; }

    public void setAccountId(Long accountId) {
        this.accountId = accountId;

The value of the account is used to determine the customer's net worth. Suppose we have a CustomerService interface that exposes this operation via its getNetWorth(Customer) method. One implementation of this method would be to place most of the logic in the service layer like this:

public Double getNetWorth(Customer customer) {
    Long accountId = customer.getAccountId();
    Account account = accountRepository.getAccountById(accountId);
    return account.getValue();

This is a classic example of an anemic domain model. All of the business logic is in the service layer and the domain objects are simply data containers. But in OO, an object = data + behavior, right? So how do we push this behavior back to the domain layer?

This biggest question in this particular scenario is how can a Customer object obtain a reference to its Account object? Well, there are several ways:
  1. It could be given a reference to the Account object by the CustomerService object. But that really isn't much different than the example above. The CustomerService class is still two involved in the business logic.
  2. This Customer object could actively obtain a reference to the AccountRepository via a service locator. But this introduces a dependency not only on the AccountRepository, but the service locator as well - not a very transparent solution.
  3. The AccountRepository object could be supplied to the Customer object using dependency injection. This makes sense - after all, we are doing this with our Spring beans already in our service/data access layers.
Implementing option #3 is where AspectJ comes in. While Spring manages the lifecycle of service and data access beans, it does not manage the lifecycle of domain objects. These can be instantiated via new or by another framework, such as Hibernate. However, AspectJ can weave advice into the domain object's classes that is executed after their constructor completes. There are several pieces to this puzzle. First let's take a look at the "enriched" SmartCustomer class:

public class SmartCustomer extends Customer {

    private AccountRepository accountRepository;

    public AccountRepository getAccountRepository() {
        return accountRepository;

    public void setAccountRepository(AccountRepository accountRepository) {
        this.accountRepository = accountRepository;

    public Double getNetWorth() {
        Account account = accountRepository.getAccountById(getAccountId());
        return account.getValue();


Now a Customer object can obtain a reference to its associated Account object via the AccountRepository. But how does it obtain a reference to the AccountRepository? Notice the @Configurable annotation. This is basically a marker that identifies this class as needing to be configured by Spring whenever a new instance is created. This "magic" is possible because AspectJ weaves in advice into the SmartCustomer's constructor. I have not delved into the details, but I suppose this advice is aware of the Spring application context.

Spring knows how to configure each instance of this class from a prototype bean configured in the application context:

<bean id="smartCustomer" abstract="true" class="org.springdallasug.aspectj.domain.SmartCustomer" scope="prototype" >
    <property name="accountRepository" ref="accountRepository" />

Now every instance of the SmartCustomer class will be wired with an AccountRepository object. In order to make this happen, AspectJ must weave this advice into the SmartCustomer class. For my demo, I chose to use load time weaving. This is done by starting the JVM with the following option:


This enables AspectJ to weave advice into classes as they are being loaded into the JVM. For anybody interested, I have packaged up this simple demo. The entire mechanics behind this can be found in the Spring documentation.

So, it is pretty cool that Spring + AspectJ makes it straightforward to apply dependency injection to domain objects. But the question remains, is this the right thing to do? Taking the example above, allowing a Customer object to completely contain the logic of calculating its own net worth means it needs access to its Account object. But this, in turn, means giving it access to the AccountRepository. This is, for me at least, an unusual design decision. While this does create a "richer" domain model, at adds more (potentially complex) dependencies into the domain model.

I don't think the answer is cut and dry. Instead, it probably needs to be fleshed out in a "real world" application. I just might have to try that.

Craig Walls pointed out a couple of improvements to this example. First, I added the name of the prototype bean to the annotation to be more explicit (I also added the "id" attribute to the SmartCustomer bean in the Spring configuration file). Second, I made the prototype bean abstract, which prevents the Spring container from ever instantiating an instance - it is now strictly a prototype. Not a big thing, but it is an improvement. Thanks Craig.

Thursday, September 21, 2006

AOP meets DDD

Yesterday I attended the Dallas Spring Users Group. The September speaker was Ramnivas Laddad. The topic of the presentation was Spring AOP and AspectJ. I was interested in hearing about how Spring leverages the AspectJ pointcut syntax in Spring 2.0. I am quite familiar with Spring 1.2's type of AOP. I have experimented with the AspectJ pointcut language, but I wanted to get some guidance on best practices.

Well, this topic was covered quite well. But at the end of the presentation he focused on how to leverage the full power of AspectJ - advising classes vs. advising objects via proxies. One of the last slides he presented was how to use AspectJ to inject dependencies into domain objects. This point was sort of mentioned in passing, but it raises a very interesting debate. Is using aspects to inject domain objects with dependencies (possibly service-type objects) the right way to create a richer domain model?

After the presentation we discussed a concrete example. Suppose you have a Customer object. In the domain, the Customer has an Account, but in the object model, a Customer object only has a reference to its Account's id (following the notion of an aggregate root in domain driven design). Now suppose the service layer supports the method getNetWorth(Customer). Without a rich domain object, the service would be responsible for retrieving the Account object on behalf of the Customer object and returning the value of the Account. Something like this:

Account account = accountRepository.getAccount(customer.getAccountId();
return account.getValue();

t suppose we want this logic to exist in the Customer object, as it should with a rich domain model. How would the Customer object obtain a reference to its Account object? The answer is it needs access the AccountRespository, And AspectJ + Spring can help achieve this. Basically, an AspectJ aspect (woven into the Customer class) would be invoked that would inject the AccountRepository bean from the Spring context whenever a Customer object in instantiated.

Now, for those who are knee-deep in full blown aspects, this is probably not a novel idea. But for those of us who have simply lived in the proxy-based aspect world., this opens up a whole new realm of possiblities. The implication of having a rich domain model (as opposed to much of the business logic remaining in the service layer) is quite intriguing. However, it raised many questions:

  • Is going whole-hog aspects right for my application? Going from proxy-based AOP to full-blown aspects is not a small step.
  • Is giving the domain layer access to other services/data access objects a good design?
  • What sort of recursive dependencies will be introduced when the domain becomes aware of these layers?
I am looking forward to delving into these questions. The possibilty of having "real" domain layer is way too interesting to ignore, I am not ready to drink the Kool-Aid, but I am ready for a taste.