What exactly is Domain Driven Design (DDD)?

We have been using many of the principles and patterns of DDD over the past many years. During domain modeling we have often used the concepts of boundary contexts, entity objects, value objects, aggregates and repository pattern, etc.

But based on my humble experience, I think DDD is much more than the usage of these patterns. DDD is a "thought-process" - the way you think about the problem domain, the way you interact with the domain experts & business stakeholders and the way you articulate the technology realization of the business need. This in a nutshell is the greatest boon of following DDD. The business and IT speak the same 'ubiquitous' language and this in turn bridges the "Business-IT gap" :)

That's the reason, the famous DDD book by Eric Evas states that DDD tackles Complexity in the Heart of Software. Mapping your software model as close to the real-life domain as possible helps us in managing the complexity of our design solutions.

The Microsoft Spain team has some pretty good documentation on this philosophy of DDD, which is available for download here. Also a neat ASP.NET example of a n-tiered DDD application is available for download.

MVP Vs MVC pattern

I was recently working on a .NET Smart Client application and came across the 'MVP' (Model View Presenter) design pattern. Having spend years developing applications on the MVC (Model View Controller) pattern (e.g. Struts, Webworks, ROR, etc.), I was intrigued to find out the difference between MVC and MVP (if any)
The core principle behind MVP and MVC remain the same - clean separation of concerns between the presentation tier and the business tier.
Some consider MVP to be a subset of MVC and there are tons of articles on the web giving differences between the two..I found most of the information muggy and more confusing. Finally I came across Phil Haack blog that explains it in simple and lucid words.
Snippets from his blog:

The two patterns are similar in that they both are concerned with separating concerns and they both contain Models and Views. Many consider the MVP pattern to simply be a variant of the MVC pattern. The key difference is suggested by the problem that the MVP pattern sought to solve with the MVC pattern. Who handles the user input?

With MVC, it’s always the controller’s responsibility to handle mouse and keyboard events. With MVP, GUI components themselves initially handle the user’s input, but delegate to the interpretation of that input to the presenter.

In modern GUI systems, GUI components themselves handle user input such as mouse movements and clicks, rather than some central controller. Thus MVP pattern is widely used in WinForms, .NET SmartClient Factory, etc.

In most web architectures, the MVC pattern is used (e.g. Struts, ASP.NET MVC, ROR, Webworks), whereas MVP pattern is mostly used in thick client architectures such as WinForms.