Firstly, if you don't know that you need it then it's possible that you don't need it. If you don't recognize the problems that DDD solves then maybe you don't have those problems. Even DDD advocates will frequently point out that DDD is only intended for large (>6 month) projects.
Assuming that you're still reading at this point, my take on DDD is this:
DDD is about trying to make your software a model of a real-world system or process. In using DDD, you are meant to work closely with a domain expert who can explain how the real-world system works. For example, if you're developing a system that handles the placing of bets on horse races, your domain expert might be an experienced bookmaker.
Between yourself and the domain expert, you build a ubiquitous language (UL), which is basically a conceptual description of the system. The idea is that you should be able to write down what the system does in a way that the domain expert can read it and verify that it is correct. In our betting example, the ubiquitous language would include the definition of words such as 'race', 'bet', 'odds' and so on.
The concepts described by the UL will form the basis of your object-oriented design. DDD provides some clear guidance on how your objects should interact, and helps you divide your objects into the following categories:
- Value objects, which represent a value that might have sub-parts (for example, a date may have a day, month and year)
- Entities, which are objects with identity. For example, each Customer object has its own identity, so we know that two customers with the same name are not the same customer
- Aggregate roots are objects that own other objects. This is a complex concept and works on the basis that there are some objects that don't make sense unless they have an owner. For example, an 'Order Line' object doesn't make sense without an 'Order' to belong to, so we say that the Order is the aggregate root, and Order Line objects can only be manipulated via methods in the Order object
DDD also recommends several patterns:
- Repository, a pattern for persistence (saving and loading your data, typically to/from a database)
- Factory, a pattern for object creation
- Service, a pattern for creating objects that manipulate your main domain objects without being a part of the domain themselves
Now, at this point I have to say that if you haven't heard of any of these things before, you shouldn't be trying to use DDD on any project that you have a deadline for. Before attempting DDD, you should be familiar with design patterns and enterprise design patterns. Knowing these makes DDD a lot easier to grasp. And, as mentioned above, there is a free introduction to DDD available from InfoQ (where you can also find talks about DDD).
