Domain Driven Design

What do I mean by data and domain-centric approaches? Data-centric generally means that you build your system around your understanding of the data you’ll be interacting with. The typical approach is to first model your database by creating all the tables, columns and foreign key relationships, and then mimicking this in C#/VB.NET. The reason this is so popular amongst .NET developers is that Microsoft spent a lot of time automating the mimicking process with DataAdapters, DataSets and DataTables. We all know that given a table with data in it, we can have a website or windows application up and running in less than 5 minutes with just a few lines of code. The focus is all about the data – which in a lot of cases is actually a good idea. This approach is sometimes called data driven development.

Domain-centric design or, as it’s more commonly called, domain driven design (DDD), focuses on the problem domain as a whole – which not only includes the data, but also the behavior. So we not only focus on the fact that an employee has a FirstName, but also on the fact that he or she can get a Raise. The Problem Domain is just a fancy way of saying the business you’re building a system for. The tool we use is object oriented programming (OOP) – and just because you’re using an object-oriented language like C# or VB.NET doesn’t mean you’re necessarily doing OOP.

The above descriptions are somewhat misleading – it somehow implies that if you were using DataSets you wouldn’t care about, or be able to provide, the behavior of giving employees a raise. Of course that isn’t at all the case – in fact it’d be pretty trivial to do. A data-centric system isn’t void of behavior nor does it treat them as an afterthought. DDD is simply better suited at handling complex systems in a more maintainable way for a number of reasons – all of which we’ll cover in following chapters. This doesn’t make domain driven better than data driven – it simply makes domain driven better than data driven in some cases and the reverse is also true. You’ve probably read all of this before, and in the end, you simply have to make a leap of faith and tentatively accept what we preach – at least enough so that you can judge for yourself.

(It may be crude and a little contradictory to what I said in my introduction, but the debate between The MSDN Way and ALT.NET could be summed up as a battle between data driven and domain driven design. True ALT.NETers though, ought to appreciate that data driven is indeed the right choice in some situations. I think much of the hostility between the “camps” is that Microsoft disproportionately favors data driven design despite the fact that it doesn’t fit well with what most .NET developers are doing (enterprise development), and, when improperly used, results in less maintainable code. Many programmers, both inside and outside the .NET community, are probably scratching their heads trying to understand why Microsoft insists on going against conventional wisdom and clumsily having to always catch-up.)