What is the difference between procedural code and Domain Driven Design style code?

Question

I am going through Domain Driven Design(DDD) techniques and I am feeling like I didn't understand it well yet.

DDD suggests putting the business logic(not infrastructure stuff like persistence, security etc) in Domain Objects, Repositories for Persistence, Aggregators for assembling Domain Objects for Client(Presentation), Services which are thin layer on top of the Domain objects and Repositories, Aggregators and acts as Transactional boundary.

Let me put it in this way:

In DDD, ViewController --> SomeService --> {Domain Objects, Repositories, Aggregators}

In my current (Procedural style) approach: ViewController --> SomeService --> DAO/Repository

Here ViewController talks to one or more Services to pull/push the data from/to the database using DAOs. If any business logic which only operates on properties of a Domain object will be in a method in that Domain Object itself. And finally the data got from service(s) are aggregated into DTOs to be presented in View Layer.

So to me both approaches almost looks similar.

Can someone explain me what I am missing?

P.S: I am adding some more info to better explain my question. In theory everyone is saying DDD suggests "Logic should be in Domain Objects". OK. Let us take a real scenario.

In ShoppingCart application, some user placed an Order. To process the Order I need to do all the following sub-tasks:

1. Get Each Item details and calculate the total Order Price.

2. Get the Delivery Address and Validate it using some Address Verification Service

3. Validate/Authenticate CreditCard Details

4. Save all the Order related info into DB

So by following DDD I will put the logic,

1. Order Total calculation in Order object which loops through its List objects.

2. In Address Object i would have validate() method which invokes some BING address validation.

3. In CreditCard class I would have authorize() method which calls some CCAuthorizationService to authorize using some third party services.

4. Save all order stuff into DB using some Repositories.

All these steps will be triggered by calling Order.process()

If this is correct DDD approach? If it is, our Domain Objects directly interacting with Repositories which seems to be violation of separation of concerns.

If this is not correct DDD approach, can some one please tell me how do you design for the above usecase?

Answer 1

DDD is language independent, it's about understanding the domain through experts and building a common language with which you can talk about the domain. So it cannot be compared directly to functional, procedural or object oriented programming languages, as they're not comparable.

View Controllers are specific to MVC frameworks and aren't specific to DDD.

In MVC a DTO for preparing data for the view would be a View Model.

Hope some of this helps.

Answer 2

It boils down to where the logic lives. In DDD logic primarily goes into the model layer so it stays near the data. In procedural code, logic goes into transactional layers so it is separated from the data. Fowler has a good description you can read about here.

Answer 3

They are similar.

Hopefully you're actually comparing "OOP" with "DDD". DDD is a subset of OOP (IMO), or at least should be in an OOPL. DDD is a specific way of thinking about breaking up responsibilities.

Answer 4

It's not about the technology or OOP or anything like that. It's about focusing on the domain at hand, the language used by domain experts, understanding the domain and modelling that domain so that important concepts are present in the code.

It was originally done using OOP and many claimed that it could only be done using OOP. However, lately people like Greg Young have shown how to do DDD in functional languages and still keep the focus on the domain.

Procedural code tend to ignore all that and just focus on how to read/write data from whatever datasource there is. e.g. integrating with a system like Movex there will be a billion tables and columns with completely retarded names like TAXEM.YAROOD FOOB.AAR which makes no sense to anyone reading that code...