The ideal is a model that automatically updates both the code and the database. It is actually not that difficult to do, and definitely worth the investment on a long-term project.

You made an interesting point about differences in friction when the developing from POCO’s or from the data model, but I think that your estimation of coding from the data model isn’t entirely clear.

It appeared to me that you’re saying that it’s easier to use the POCO’s because when bringing the model into play from the database, the tooling has a higher coefficient of friction than in simply spec’ing a POCO model.

If I read you right, it seems to be a comment about the tooling rather than the nature of the impact to the process when the model comes into play through POCO’s or through the database.

In Rails, I introduce all model changes incrementally using migrations. I can change the model a column at a time if needed.

As long as we can propagate micro-incremental changes from either representation in a low-friction way, we’re in good shape.

Choosing Active Record or Domain Model should be a decision that’s made because of the benefits that the patterns bring to the solution rather than the friction that either causes.

The tools that we have in .NET to harmonize the models micro-incrementally don’t serve either Active Record or Domain Model really well yet.

Imagine a plug-in that that generates a property from test-code that also adds mapping and modifies the database