ORM tools and various design approaches - how do they fit?

Good day!

I am a student and I am doing a study on ORM tools and how they fit into various software design patterns and
approaches. For now I have tried some tools and read about their weaknesses and strengths related to MVC
and n-tier design patterns and also have an experience with some projects. But lately I have found out
about those concepts: data-driven design (is it the same as data-driven architecture or those are two
different things?), domain-driven design, model-driven design. And I got a bit confused how does this
all fit together with ORM and what is ORM role in those designs.

There are tools like Hibernate which allow users to create mappings and classes as they wish. I have seen a
project where developers create almost 1:1 mapping (except some business object related properties)
for almost each database table and use entity classes only as a new datatypes without implementing any
functionality in them. All the basic CRUD functionality and business logic in that particular project is
implemented  in a „business object factory" layer. I guess it is not the best way of using object-oriented
design because our business objects are really just some "property bags", but still – what design model
it is then; how do you call it? I guess it could be based on model-driven because we used electronic
implementations of various physical paper documents and their relationships as a basic building elements.

In the project we tried two technologies. The first was NHibernate. We ended up with creating many similar
entities, similar business object factory classes and similar web services – it was a big
"copy-paste-rename-customize BOF classes to fit the particular document operations" work but we were
lucky that NHIbernate allows to treat all the entities the same way – dynamic filtering methods which can
be used for any entity were so simple to write and use. We tried LINQToSQL and Entity framework. The good
part was - LINQToSQL and Entity framework generate partial classes with invisible CRUD mechanisms and
offer ability to extend classes and embed some business logic – I guess this would be more close to OO
principles then our "property classes". But it was really hard to create some generic operations with
entities, especially universal filtering. So we stayed with NHibernate. Also in our project we used
SharePoint and Infopath "because the client said so". Infopath forms need strict data definitions with
XML schemas and they are really hard to develop and debug if you try to put some more code than data
validation (I guess it would be completely wrong design to put some business logic into Infopath form). 
As I understand, data-driven architecture means that instead of creating many web services/UIs for each
kind of our entities, we create some more or less "universal" services and UIs and then create some data
model to tell our services and UIs what kind of entity we are working on. As the Infoapth needs strict data
sources we could not develop them "data-driven" way – we would spend too much time trying to create
universal Infopath form and universal web service to reuse it for many kinds of our entities. I wonder if
this problem is one if the reasons why „data-driven architecture" has been called a not-so-good idea
lately (especially when developing for SOA)? So we continued to "copy-paste-rename-customize" for
Infopath forms and web-services. 

There are „active-records" kind of ORM tools, where entities have CRUD embedded inside.  Does it mean that
the right way would be to go even further and implement also some business logic into those entities and
only after that try to tune the actual mapping to get our business entities to persist somewhere? 

And finally I got to domain-driven design. How ORM tools fit in there? And how should a good OR/M tool behave
itself in domain-driven design? 

Where is the point when domain-driven design connects with entity model and ORM and how should we work if we
are forced (by client) to use some technology which has some limitations?

Uhh, I have written so many questions. But I just could not find any literature where ORM tools are explained
in context of various design approaches and how to use ORM tools the right way to follow good OO design. And
more important – if domain-driven design is "so cool thing" then what would be the most appropriate way
for an ORM tool to be implemented to fit DDD (would be really nice to see some practical examples and
analysis like – "this tool does not fit because …; this tool would fit if only …")? 

If you could suggest some literature I would be grateful.

Thanks.
Martin.

------------------------------------