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.
Sign up here with your email
ConversionConversion EmoticonEmoticon