Domain driven design

Almost every developer will agree that DDD is important. But what is DDD and why exactly is it so important? The best way of looking at this is to consider the conceptual differences between DDD and non-DDD scenarios.
But, you say, aren’t we are doing DDD simply by carefully separating our applications’ tiers into domain, repository, services, web, and et cetera? I can see the domain tier in my application; the only things that live in the domain tier are the domain objects, therefore my application uses DDD. Right?
Well, possibly. It is important to make clear distinction between domain objects as buckets for data and true objects, that is things with data and behaviour. A good indication of buckets of data situation is where your services contain a lot of non-transactional logic that shuffles data in your domain objects. A system implemented in this way is very similar to the old-school procedural programming approach. In procedural systems, there are no objects, there are only data structures and procedures that operate on those data structures. Keep term here is data structure; a data structure can be very rich:

typedef struct __INVOICE_T {
  int id;
  char invoice_number[100];
  supplier_t supplier;
  date_t invoice_date;
  invoice_line_t *invoice_lines;
} invoice_t;

in C is not that different from

public class Invoice {
  int id;
  String invoiceNumber;
  Supplier supplier;
  Date lastLogin;
  List invoiceLines;
}

The similarity is striking. Both structures (the C structure and the Java class) are simply holders for data. Both objects hold enough information to calculate the sum of all net amounts on all invoice lines. This is where the difference between procedural and true DDD code becomes apparent. In procedural approach, you would write a procedure (by all means in a service-tier object, but ultimately a procedure) that takes the Invoice or (invoice_t) and returns the total.
A DDD approach would be to have BigDecimal getTotal() method in the Invoice object. This is the simplest take of the DDD world; the methods in your domain objects could and should do as much work as possible. This is because the functionality of the domain objects is available to all tiers of your application.

Tags:

Leave a Reply