Is DDD must goes with AOP?

[zarick]

I am very much like the idea of DDD, but when I am going to impl
it in one of my current project, I found that it is not really possible without
introducing real aspectj into the project.

In DDD, some entities bean will have to manage the life cycle of
associated bean. For example, Order and OrderLine, but currently,
JPA beans will not have injection without using aspectj for weaving.

After all, I reverted to pushing some of the code in the service/facade
bean as they are subject to inject by Spring.

So, one question come up my mind again and again, is DDD will be served
with full AOP?

[Alarmnummer]

My personal experience is that DDD is much harder to do if you have troubles accessing the dependencies that are needed. And AspectJ certainly can help to fix that issue. So AspectJ makes DDD usable in practice.

There are other workarounds.. You could also use some kind of interceptor and inject it in Hibernate. Once an entity is loaded, the dependencies are set, but I guess there are problems with newly created entities.

If I have the chance, I would certainly go for AspectJ (compiletime... runtime gives much more problems).

[zarick]

My personal experience is that DDD is much harder to do if you have troubles accessing the dependencies that are needed. And AspectJ certainly can help to fix that issue. So AspectJ makes DDD usable in practice.

There are other workarounds.. You could also use some kind of interceptor and inject it in Hibernate. Once an entity is loaded, the dependencies are set, but I guess there are problems with newly created entities.

If I have the chance, I would certainly go for AspectJ (compiletime... runtime gives much more problems).

This is exactly what I think when trying to design the system more DDD. As I've already some experience on AOP using Spring, I'm also interested to introduce AOP into the project, however, is the use of AOP (to support DI on entities classes) common in other project?

For me, this is one of the very important question, as it influence the architecture significantly.

Does anyone share some successful and unseccussful exp. on this aspect?

[debasishg]

As I've already some experience on AOP using Spring, I'm also interested to introduce AOP into the project, however, is the use of AOP (to support DI on entities classes) common in other project?

With transparent persistence support from ORMs like Hibernate and JPA like contracts, along with declarative lazy loading features, I am not sure how much of DI will you require on entities. I had the same feeling earlier, but found that it is not at all a frequent use case in real life applications. I would recommend a clean entity model, based on pure POJOs, with relations formed only using POJO associations. It is easier to maintain and unit test without any dependency on third party frameworks.

Cheers.
- Debasish

[Andreas Senft]

If I have the chance, I would certainly go for AspectJ (compiletime... runtime gives much more problems).

Out of curiosity: What runtime problems are you referring to? Is it about classloading issues and possible interference with other bytecode enhancing libraries?

Regards,
Andreas

[Alarmnummer]

Out of curiosity: What runtime problems are you referring to? Is it about classloading issues and possible interference with other bytecode enhancing libraries?

Regards,
Andreas

One of the problems I encountered is that the aspectj agent needs to be added at startup. This can be a serious issue if you are not the 'owner' of the server the application is going to run on.

We also had other issues, so that is why I now prefer using compiletime aspectj (but that can be a bitch with maven.... maven is the bitch actually )

[Alarmnummer]

This is exactly what I think when trying to design the system more DDD. As I've already some experience on AOP using Spring, I'm also interested to introduce AOP into the project, however, is the use of AOP (to support DI on entities classes) common in other project?

For me, this is one of the very important question, as it influence the architecture significantly.

Does anyone share some successful and unseccussful exp. on this aspect?

I have used it with success on quite a few projects. But make sure that all non coding issues are fixed as well: compiletime/runtime aspectj.. aspectj agent.. spring version allowed to use.. etc.. Maybe you could make a POC to prove that it works for you and your environment. Once you get the first bean up and running, the others will follow.

[Andreas Senft]

One of the problems I encountered is that the aspectj agent needs to be added at startup.

It seems that at least this issue seems to be addressed now, as I recently read here.

As yet I have not used AspectJ in productive systems and I am still inconclusive about compile-time vs. load-time usage. I guess I have to investigate this further when the need arises.

Regards,
Andreas

[al0]

It seems that at least this issue seems to be addressed now, as I recently read here.

As yet I have not used AspectJ in productive systems and I am still inconclusive about compile-time vs. load-time usage. I guess I have to investigate this further when the need arises.

Regards,
Andreas

Sorry, but it is not exactly so. If you would read "6.8.4.6. Environment-specific configuration" in the same document to which you have referred, you will notice, that you still need to specify JVM startup parameter for most application servers/servlet containers (with only few exceptions).

Regards,
Oleksandr

[Andreas Senft]

Sorry, but it is not exactly so. If you would read "6.8.4.6. Environment-specific configuration" in the same document to which you have referred, you will notice, that you still need to specify JVM startup parameter for most application servers/servlet containers (with only few exceptions).

That is true. Though I didn't intend to state that the problem is completely solved now. I also saw that Tomcat and Glassfish support is work in progress for 2.5.1. So together with Weblogic and OC4J support that covers some field already. Hopefully, further environments will/can be treated similarly in future.

Regards,
Andreas