domain driven design - Why not split the data access layer into two? -

everywhere look, noticed both domain driven design (ddd) , entity hydration approaches attempt populate entities directly data layer. disagree such approaches. not because these approaches not work because these do. instead, argue such approaches give low level of transparency testing purposes. propose @ data access layer, data retrieved populate dictionaries instead of directly populating entities themselves. there several reasons this:

first, there greater flexibility. dictionary per result set populated. decide later entities populated these result sets.

second, less knowledge data layer needed determine data retrival failing. may still write tests verify data retrieval without having understand associated complex domain entity factories.

there 1 so-called disadvantage, performance? going through 2 layers slower going through one? yes, performance gain going through single data layer negliable here. reason because both dictionaries , entries these dictionaries populate cached. so, if there memory overhead. think worthwhile gain 2 advantages stated above.

it seems testing issue ("for testing purposes"), suggest use repositories @tschmuck pointed out.

as ayende points out, might give unnecessary lasagna code (i.e. many layers), give flexibility. can implement fakes/test spies yourself, mock , stub 'em, use in-memory db such sqlite, , dependent class happy.