Very true. I believe developers who build enterprise systems need to understand the architectural overview of where their system fits into the bigger picture, and the value of an optimized data model that can meet downstream needs as well (even if they can't build it). I definitely understand the "impedence mismatch" of hooking into, say, a complex CRM schema and then wrapping business rules around it while trying to present unified entity views in the application. The article sounds like DDD takes a customer object, serializes it and dumps it into Customers.xml or an XML field. I can see how this would speed your development time...

Does DDD just dump Entities into a Repository from the business tier in their current state? Or can it coexist with a normalized, storage/retrieval optimized data model?