Forkwind Part 4: Domain Driven Design and Record Driven Design

Forkwind is a tutorial on how to build a well designed .net application. This is the 4th part of our forkwind implementation. If you are not aware of the master thread and forkwind, please go here first for introduction.


Introduction:

In this part, we are going to dive in to some theory again. We are going to discuss two design methodologies. Domain driven design and record oriented design. In my honest opinion both methodologies are decent. But slowly record oriented design isbecoming obselete. Actually this discussion is not very popular in the software world beyond .net. Most of the recent frameworks like rails and java frameworks use domain driven design as de facto standard. .NET world however is quite lagging in this manner.

What is Record Oriented Development ?

I am not going to make a formal definition. But in practice, record oriented development focuses on the records within the database. It is record centric in a sense. Database records are passed within layers. Records are just mere containers and having no semantic meaning. In .NET world datasets used together with datatables are good examples to this methodology. They are mostly typeless but just records. In .net 2.0 we had Typed Datasets but they are merely generated code.

Usually the first step in record driven development is to design the database , tables and relations and build your application on top of that. If we were developing Forkwind in a record oriented manner, then first we would have created tables like Company, Product, Supplier ,etc


What is Domain Oriented Development ?

In domain driven development, we define domain entities to solve our particular problem. It is a more object oriented approach. For example Forkwind is an application to keep track of orders to customers and suppliers. So we create typed objects like Customer and Supplier as a first step. We generally ignore the database design to later part thanks to ORM tools and object databases. Though there is one exception to that : If the database is already created and with full of data then we have to adapt our domain entities according to that tables. This is a common and painful scenario with domain driven development.



Why domain driven development is not popular in .NET ?

This has historical reasons. Before .NET, I was coding with MFC and pure Win32 for gui stuff in windows. Frankly speaking both MFC and Win32 was dirtier than my toilet. The api was terrible. Then came the Visual Basic 6. When VB6 emerged, my neigbour's son became a more productive programmer than I am. VB6, which I never liked, allowed developers quickly design applications. Managers liked it very much because all that matters was the software running. They are not concerned with the maintenance nightmare coming from "Quick and Dirty" approach of VB6. I also conspire Bill Gates himself was a big pusher of Visual Basic because of his personal sympathy to BASIC. VB6 was using ADO to connect database which is completely record oriented. So when .NET emerged , record oriented approach already widely accepted in .net world. Also microsoft used this fact to sell its IDE so called Visual studio to show how easy to create an application just by dragging and dropping a database table to the screen. They made a propaganda on that this approach such that you are suppose to produce quicker (but dirtier) applications and you will save money on development costs (but lose on maintenance). The last reason is the Microsof's failed ORM Mapper called Objectspaces. Microsoft was planning to deliver this ORM mapper with Visual Studio 2005. But project failed miserably. So MS silently carried on ignoring domain driven development methodologies till 2007-2008 where we have linq to sql and ADO.NET Entity framework now.

Enough history let's get into technical details:

Domain Driven Development Pros:

* More Object Oriented approach
* Much better maintenance
* Sounds more correct

Domain Driven Development Cons:
* Less mainstream on .NET
* Requires skill!!
* You have to use things like ORM

Record Driven Development Pros:
* Easier for novice
* Visual studio tools integrates better
* Faster development (though pace diminishes if project grows)

Record Driven Development Cons:

* Likely to lead maintenance nightmare!!!


Basically Domain driven development dissects a complex problem into smaller pieces. But it can be complex at times. Record driven approach is more simple, just get the records from the db and publish. Since we usually aim better design and better maintence in general , domain driven approach is favorable to me. And that's what we are doing in Forkwind.

In the next part * Forkwind Part 5: A first visit to unit testing: (Not Available at the moment) again we are back to coding. We will write our first unit tests for Forkwind. Till then stay tuned!!