Let’s look at ALL developers around the world. What are the average developers good at? Writing solutions, right!? So what should developers do, of course they should do what they can do best, write solutions. The most common developers write business solutions that should solve a business need(s). Some few developers write frameworks etc and I will not include them in the word “developers” in this post, those developers are the people that will help the average developers to focus on what they do best. If developers (I will now on use the word “Developer” for “average developers”) are good at writing solutions I think they should do that, don’t you think? They shouldn’t focus and spend time on the infrastructure; they should instead do what they do best, let someone else focus on the infrastructure, people that are good at it. So developers should focus more on the conceptual level instead of the logical level. If we look at Domain Driven Design, we shouldn’t care about how data should be saved, we should instead focus on the domain-model. Most developers today are used to draw conceptual models, the logical way to do things that people will understand, is to try to reflect the real world when building applications. Try to think as an object not as a computer. What some developers have problem with is to map the conceptual model they have created to an underlying data source. Some mistakes many developers do is to create the database first and then the design of application. They let the data source drive the development. Sometimes developers don’t have a choice, the companies already has a database, but why care about it when you design your application, don’t design your app after a database. Instead create your conceptual model and let the administrators of the database instead care about the underlying data source and how to map it to your conceptual model. To make this possible we need a higher level of abstraction. If we look at a data-centric application, we will now with ADO.Net Entity framework (will be shipped during next year “2008”) have a tool where we can now focus on the conceptual model and create our business entities like “customer, product” etc. Developers don’t even need care about how the underlying data source looks like. They don’t even need to care about how the data is saved, where it’s saved etc. They only make sure to change the data by working against the business entities they have created, search for the data they need, but by asking the conceptual model. No need to write SQL, no need to map the data returned from the data source to the conceptual model. We already have this kind of mapping solutions for many years back in time, the OR-Mappers. What does all this have to do with abstraction and my title of the post. Well to make sure developers focus on what they are good at, abstraction is needed. But how far can we abstract things. Look at OLE DB, it was an abstraction to make it easier to get data from a database, later we got ADO and ADO.Net, another level of abstraction to make it easier to do save and get data from the database. Now we will soon have the ADO.Net Entity Framework. Well even if developers will get the Entity Framework, they will ask more abstraction, they want to make sure things will be simpler all the time. Is this because developers are lazy people!? Well abstraction is good; because it will make sure developers do what they are good at.