Domain Modeling, Domain Objects in DDD

I'm really new to DDD and trying to grasp some of the concepts.

Could someone explain me the idea behind Domain Modeling in DDD.

I have already gone through wikipedia explanation: http://en.wikipedia.org/wiki/Domain_model but still seems like there are some gray areas in my understanding.

Based on what I understood, domain modeling involves building a model around the business entities to express their relationships, express the entities that participate in the model etc..

Isn't this something that has been in practice always? in Object Oriented world, you model business entities into classes, objects etc.. and build the software around this.

What I do not understand is the emphasis Domain Modeling gets in DDD. Is it the sam开发者_JAVA百科e object/class modeling that you find in OO world, or is this something new to DDD ? How does it differ from Object Oriented design/modeling?

Your answers are highly appreciated.

One distinction is that a "proper" implementation of the Domain Model Pattern in DDD is isolated from cross-cutting concerns.

For example, it contains nothing to do with databases or other persistence. Where it contains validation logic, it is business validation, not "does the name exceed the column length?" validation.

The idea is that the domain model encapsulates "the business" -- in business terms ("ubiquitous language"), to the extent possible -- and exposes relevant aspects of the business to "the program" without acquiescing to the needs of the software.

On the flip side, "the software" is concerned with IO, UI, and the like, but delegates all business logic to the domain model.

In principle, you can wrap your domain model up in an assembly and use it across multiple applications. When business rules change, as they do, you have one very logical place in which to affect the changes (because the model is a 1:1 or nearly-so representation of the relevant aspects of the business and is described in the same terms as the business).

The Domain in DDD does not need to be implemented in OO. In my experience an OO domain model is usually best, but there are very valid examples of situations in which it may not be.

You might implement a domain in rules, with a rule engine (example in The Netherlands where this is done for a large mortgage application). Or you might do it in a functional language. The essence is that your domain, in however fashion it is implemented, is isolated from what I usually call the technical aspects of your application (or, as the previous answer calls it, cross-cutting concerns, although I think there may very well be cross-cutting concerns within a domain). An isolating layer, which may be implemented using adapters, makes the domain as much as possible, even completely, independent from the technicalities. This layer usually leverages patterns such as Facade and Observer.