Object-Firster or Data-Firster: DDD is for CRUD Apps

Ward Bell posted an interesting read “DDD is for CRUD Apps” over on the Entites Wiki. As Ward would say, he wrote the article on the Wiki for “a number of folks with contrasting degrees of affection for and animosity toward Entity Framework.” If you haven’t had your weekly dose of EF controversy I suggest you go over and have a read.

From my comments on the Wiki: I agree that DDD ‘Principles’ can be applied to a CRUD app using a data-first approach; we currently do this now with EF and have mixed success. There is a lot of value in being able to generate a domain model of an existing schema to get up and running quickly, especially if you are talking about a fairly common crud domain where the db design has been proven time and time again (order management?). Also, there are times when large modifications, such as adding a new module are made to a database, and again, code gen from the db can save time. It seems it gets you 80%.

However for me, the last 20% is the most painful. The feedback cycle when working with the database can be expensive when flushing out the exact specification of the domain model during behavior driven testing. This gets magnified when working with large team’s across multiple environments, dealing with change scripts, db source control, test data etc. Refactoring becomes very expensive and hard on the team… “Whoops, adding those 3 columns and changing that db relation from table x to table y was a bad idea” Working with objects first in this scenario is so much easier to find the ‘true acceptance criteria’.

In a perfect world I want to be both a data-firster and an object-firster, depending on the situation. I think EF can work here, where I can use the code gen to update the schema portion of the model, and then map to existing c-space properties which I have tested prior to s-generation. You can currently do this with EF the first time through, but once you start mapping to the s-side involving existing associations, the super quantum theory AI validator kicks in and starts trying to overprotect you from making mistakes and breaking the mapping. I think turning this validation off and allowing EF to fail gracefully on bad mapping would go along way, without necessarily needing a full-blown POCO implementation to make an object-firster happy.

For me its not the persistence noise in my model classes that irritates me, its the style of development that gets enforced by mandating the schema must be updated first, every time, before I can even work with or extend the behavior of my model.