[danidiaz]

> My own solution was to keep no entity state in memory and translate everything into DB updates immediately

Did you encounter some part of the domain which was difficult to "push down" into SQL?

Also, how would this compare with encoding your domain code in a bunch of stored procedures, largely skipping a "conventional" programming language?

[moring]

I tried to keep the domain logic in the upper layer and only push down "dumb" queries -- in the sense that the queries were allowed to be somewhat complex but not allowed to contain domain logic.

This way the DB layer was not written in a "re-usable" way because it contained specialized queries like "get all users that match this and that criteria", but they usually translated directly to SQL.

Encoding domain logic in stored procedures is something I didn't try yet. It would be very nice if SP weren't second-class citizen in multiple ways. But even then, at some point I guess there has to be an interface between the domain logic and SQL queries, so the problem isn't actually solved, just moved into the database.