1-9 start/2007-02-28/1

I think we are approaching two distinct, yet closely related, subjects:

1. The use of DDD
2. Persistence of an OO model

This distinction is important to clarify things as we can have the first without the second (bare with me) and the second without the first. We can also have the first with an OO DB which changes many of the assumptions made.

Now, considering searches over the graph of objects composing the OO model resulting of a DDD.

I don't think the Search<DomainObject> concept that João described above was completly understood. The suggestion was to consider a view in a database as a regular table. So, if your persistence framework maps objects to tables, it can map and object into a view. If you then ask the framework to provide all objects of that type (a readAll) it will provide objects representing the result of a complex query "transparently".

A simple example: a bank. Lets assume that the core of the bank's domain is the relation between accounts and their owners. But "Customer" is also a relevant concept for us (the bank) and we want to decide between those customers that we would rather loose and those customers we want to keep.

I've just invented a stereotype in the example to mark those domain concepts that we will map into a view. But I believe that they are domain concepts with the same relevance as the others. They just have different domain rules. For example "a TerribleCustomer can't open any more accounts" o "a PremiumCustomer has +1% in the interest rate". The fact that these domain classes can be implemented in the database as two views it's problably only an optimization.

But this isn't the main problem enounced here.

The traversal of the object graph corresponding to the application's domain is more inefficient than direct query in a database and materialization of the result set over a database.

Well, I believe that is more inefficient if you are doing a complex (several levels deep) search, most of the graph is not in memory, and you need to materialize those intermediate objects to do the traversal. If the intended query is just 1 or two levels deep then processor speed higly overcomes the network latency/traffic normally associated with the communication to a database. Offcourse I have to do some tests to back this up (all those Prevayler related tests are out of date and unrealistic).