Doc to db

As some of you might have noticed, I'm pretty fond of Domain Model-focused design (DDD, or whatever you call it) nowadays.
;-)

Even so, I'm also very interested in SO, for example. I mean, I think it's important to keep an open mind, and try to make sense of different approaches according to the situation. When Iím in a really wild mood I even think it might make sense to combine several approaches!
;-)

That's the reason why I want to get a better understanding of what Andres is talking about here and Mats here. Let's call it "doc to db". I think I understand the overview (at least well enough to believe it's interesting and that I want to learn more), but Andres doesn't agree...
:-)

Here are some unordered questions for Andres and Mats - and anyone else, of course.
  • The borders of the docs will be static, right? Could that become a problem for flexibility?

  • Do you envision overlapping docs or not?

  • Would you recommend the solution for in-proc situations too?

  • Do you see any drawbacks with behavior-less classes?

  • Will there be many places to change if there is a change in the database? Or do you envision some central model which will be the only place to change? If so, how do you envision the implementation of that model?

  • There won't be anything like an Identity Map or a Unit of Work across several docs, right?

  • How is this better than DataSets? How is it worse?

  • If the client's platform is unknown, what to give the client then? Validation stuff anyway? If so, in what format?

  • How do we ask for a certain doc? By an enum (or similar) parameter? Or many fine grained services so the client can aggregate the doc by itself? Or only a few coarse grained services?

  • Regarding global rules (rules that require more than a single doc), will they go to the database? Or to a global doc? Or to what?

  • Would you agree if I say that a doc sounds similar to what Martin Fowler talks about in the Presentation Model pattern?