In my previous place of employment, we spent a lot of time talking and thinking about chasing the software holy grail:  a framework capable of allowing developers to focus on a small subset of the technology stack, get everything else for free from the framework, and out the other end comes a fully functional application.  Of course, that application is assumed to be user friendly, fully functional, performant, and maintainable.  Over the years I tend to mock the idea to some degree, but I’m also a big believer that developers spent way too much time dealing with things that shouldn’t have to deal with and solving problems that have already been solved.  For the record, I think it’s just as silly when people totally dismiss these ideas and believe everything needs to be written by hand.  There are serious inefficiencies in how we typically build software today, but I don’t believe the masses go about solving these inefficiencies in a realistic manner.

I believe part of the problem is people tend to falsely believe all you need is a framework capable of handling the low level infrastructure (data access, logging, and caching), a good data model and a uniform way for exposing that data model to a client… and the rest is just cranking out functionality on top of that foundation.  You typically hear people saying “for 80% of applications, that’s all you need”.  I don’t know what the real number is, but in my experience, it MUCH lower than 80%… more like 10%.  Even for the simplest of CRUD apps, this foundation isn’t sufficient.  Such a foundation only your persistence model.  By “persistence model”, I mean creating a normalized physical database schema and exposing that through some API.  Maybe your API is a series of stored procedures; maybe its a set of hand written queries; or maybe its a set of data access objects; or maybe it’s a set of NHibernate or Entity Framework entities.  The belief seems to be that with this in place and available to your UI, the rest of building the app can be inferred and/or built by monkeys.  Like I said, I think it’s a fallacy - but I do think there’s a holy grail there to be found.  However, it can’t be built by monkeys.

Creating a rich domain model is the holy grail.  “Domain model” is a very overloaded term.  At my previous employer, “domain model” meant your “persistance model” – in fact, the “domain layer” was the name given to the data access layer.  The belief was that the data was your domain.   Like Eric Evans in his book Domain-Driven Design: Tackling Complexity in the Heart of Software and all of the Domain Driven Design (DDD) practitioners out there, when I say “domain model” I’m referring to the Domain Model pattern defined by Martin Fowler.   It is the code in your application that encapsulated the behavior of your domain.  That behavior requires data and often persistence, but the focus is on the behavior – not the other way around.  From that, I believe you can infer the persistence… as well as a lot of other things.

That is something I believed very strongly 5 years ago after reading Eric’s book and studying Martin Fowler’s work – and I still do today.  I always struggled to convey this idea to my previous coworkers.  They are all brilliant people with a long background in database modeling and they simply think in terms of persistence.  That is how they are wired.  It’s hard to get them to think any other way.  The other day on my drive home I was listening to the Inside the Naked Objects Framework with Richard Pawson episode of Hanselminutes and all this came rushing back to me.  I know nothing about Richard Pawson’s framework, but this immediately sounded like something my last employer should study heavily.  I especially found interesting the last 2 minutes where Richard talks about how Trygve Reenskaug (inventor of the MVC pattern) reviewed his thesis on Naked Objects and said this was the final piece they envisioned but never created for MVC back in the 70’s.

I’m definitely going to be checking this framework out in more detail in the very near future.