Domain Driven Design

Domain-Driven Design (DDD) is a collection of principles and patterns that help developers craft elegant object systems. Properly applied it can leadto software abstractions called domain models. These models encapsulate complex business logic, closing the gap between business reality and code.

Basic Components:

* Entities Have an Identity and a Life

An entity is a "thing" in your system. It's often helpful to think about these in terms of nouns: people, places, and, well, things.Entities have both an identity and a lifecycle. For example, If I want to access a particular customer in some system, I can ask for her by a number.When I complete a order, it's then dead to my system and can go to long-term storage (the historical reporting system).

* Value Objects

Describe Things Value objects are descriptors or properties important in the domain you are modeling. Unlike entities, they do not have an identity; they simply describe the things that do have identities.

* Aggregate Roots Combine Entities

An aggregate root is a special kind of entity that consumers refer to directly. Identifying aggregate roots allows you to avoid over-coupling the objects that comprise your model by imposing a few simple rules.

* Domain Services Model Primary Operations

Sometimes you have operations or processes that do not have an identity or lifecycle in your domain. Domain services give you a tool for modeling these concepts. They're typically stateless and highly cohesive, often providing asingle public method and sometimes an overload for acting on sets.

* Repositories Save and Dispense Aggregate Roots

Where do you go to retrieve entities? How do you store them? These questions are answered by the Repository pattern. Repositories represent an in-memory collection, and the conventional wisdom is that you end up with onerepository per aggregate root.

* The Thing with Databases

By this point, I'm sure you've thought, "This is all well and good, Dave.But where do I save my entities?" Yes, you have to deal with this important detail, but how or where you persist your models is mostly tangential to anoverview of DDD.

Article Reference:http://msdn.microsoft.com/hi-in/magazine/dd419654(en-us).aspx

The Official DDD site: http://domaindrivendesign.org/