{quote}As you know - since you've already been developing code at FenixEdu - a thin service layer can be present in DDD approaches offering transactional support. By thin layer I mean dumb services, in other words, services that are not aware of business logic - that will be taken care by the objects - and will only do gets and sets of objects.{quote}

Well, I was just mentioning the standard approach developers often use with SOA. In my current project, our project leader decided to use a ThreadTransactionManagar that is used in every entry-point on the service layer (I although I do not want to elaborate further, I ca still say I dislike that approach). Basically the transaction manager offers one transaction per thread, allowing us to use nested service calls :S.

{quote}But… now that you've mentioned aspects, that seems an interesting interesting approach! What's the main idea? Mark a setter as transactional?{quote}

When I mentioned Aspects, I was referring to the process of adapting an already framework to transparently use the transactional system. I have had some time with NHibernate now, so I can safely say it is not a good think when programming DDD. First, there is the need to create a Session context for each service (transactional unit), and that does not merge well with our DDD approach. After that, for each modification we have to call object.save() to persist changes. And to create/delete we have to call static methods on the Domain class. This is not a very good DDD way of doing things. My naïve Aspects comment was about calling save after each setter (which in the end does not offer a full solution)... Comments are more than welcome...

I did thought about some other approaches, namely only persisting changes on the persistence layer upon commiting, and walking the graph of objects to determine creations/updates/deletes. However this approach requires the use of an Software Transaction Memory manager, which is exactly what you guys use @ fénix.

{quote}Other idea - never tried it so I'll just hope this doesn't backfire on me - was to use >>lucene as your domain object indexer. With following "rules":{quote}

Regarding searches, I will add only this: you are still throwing away performance when you want to search across multiple tables (read joins).

Should anyone come up with a good solution, please do tell me... Although I pretty much doubt such would exist...

Edit: I found some good reading about the subject
- http://debasishg.blogspot.com/2007/02/domain-driven-design-inject.html
- http://debasishg.blogspot.com/2007/02/domain-driven-design-use-orm-backed.html

And I would recommend reading some other posts that are off-topic for this discussion.