{quote}
With SOAs, the transactional unit is often a service,
{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.

In my opinion the introduction of such thing layer might be  a mixing between SOA and DDD. But it seems one of the best approaches to deal with transactional context, still why don't you share some of the ones you've already seen?

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

Though I guess that there would be a drawback the compilation time would increase drastically (remember when we tried aspects on Fenix for Software Testing class?). Though a selective weaving might fix that problem, not sure about that though.

{quote}
Another point that I think is worth noting is object search. Another frequent question I get is how do I do a search with a set of criteria.
{quote}

To me that's probably one of the biggest problems you might have in DDD, or maybe I just lack of experience on such problem. 

Using DAO's in DDD can be done, although that's punching DDD approach in the face. So I prefer to leave it aside.\\
Using OQL-like functionalities like the ones given by Hibernate - or any other persistence framework - can be an option, although I don't know if will be a really good one.

Other idea - never tried it so I'll just hope this doesn't backfire on me - was to use {link:lucene|url=http://lucene.apache.org/} as your domain object indexer. With following "rules":

1. You wouldn't be indexing the object itself but only certain object fields. 
1. Those fields would be marked as index on your (possible) Domain Modelling Language
1. There would have to exist a re-indexing system for creation, update and deletion of domain objects. 

I already have experience with lucene, {link:dspace|url=http://www.dspace.org/} uses it to search in repository's meta-information. Just to leave an idea of performance I can retrieve hundreds - if I'm not wrong the largest search result I got was something around 4000 hits - of relevant hits on a search in something like __one__ second.

Other approaches to search might be:

* Indexed reading where you still mark on your domain modelling language certain field as indexed and the DDD framework allows you to apply some sort of criteria reading. This is almost like OQL although not breaking the DDD concepts - at least I don't think it does.

* In Memory Search, read all your search domain into memory and iterate through it finding the objects that do match your criteria. This is definitely __not__ a good option since it does not scale at all.

Any other ideas are always welcomed.