0

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?

K. Siva Prasad Reddy
  • 11,786
  • 12
  • 68
  • 95
  • What do you mean by "business logic which only operates on properties of a Domain object" ? What you may be missing IMO is that your current approach is not exactly what's generally called procedural code... – guillaume31 Aug 10 '12 at 19:56
  • I mean if there is any calculation to derive some value which are only based on the properties of one domain object then the method which performs the calculation should be in the Domain Object only instead of Service class. – K. Siva Prasad Reddy Aug 13 '12 at 07:38

4 Answers4

1

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.

Garrett Hall
  • 29,524
  • 10
  • 61
  • 76
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.

Adrian Thompson Phillips
  • 6,893
  • 6
  • 38
  • 69
  • Adrian, you are right. DDD is language independent. I am looking forward the way to implement a solution by following DDD approach. Finally we need to covert this DDD concept into code right. Can you tell me how do you approach for the above mentioned ShoppingCart scenario in DDD style? – K. Siva Prasad Reddy Aug 13 '12 at 08:09
  • I'd put your credit card authorization into a Service, as it is going to involve the cooperation of more than one domain object and possibly include workflow type flow and decision making. – Adrian Thompson Phillips Aug 13 '12 at 08:15
  • Your first 2 items shouldn't require any repository access. I'd expect that creating objects would most likely be down to a factory of some sort and the 'saving' aspect would be something you could do in your domain entity/object. Architecturally you'd probably be best looking at injecting the repository by interface in the constructor using an IOC container. – Adrian Thompson Phillips Aug 13 '12 at 08:23
  • so if the task involves workflow style of process and involves cooperation of multiple domain objects then you prefer to put this workflow in a service. In this case it seems DDD = Properly written Procedural Style approach with Domain Objects having business logic methods which operates on properties of itself. Rest is same like there will be services, repositories as in procedural style. Is it good to talk to Repositories from Domain Objects? – K. Siva Prasad Reddy Aug 13 '12 at 08:25
  • It's generally architecturally awkward to access repositories from domain entities. There's some good answers to this in this article: http://stackoverflow.com/questions/827670/is-it-ok-for-entities-to-access-repositories – Adrian Thompson Phillips Aug 13 '12 at 08:33
  • Domain Objects creation from IOC container!!! Yes it is possible..but looks like making things more complex..Even for testing also we should get Domain Objects from some Container/Factory/ManualWiringDependencies. May be i am feeling like this as I am get used to Traditional(Procedural) style of coding. But I will try this DDD on my pet project first and see how it goes. Thanks a lot Adrian :-). – K. Siva Prasad Reddy Aug 13 '12 at 08:34
0

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.

Dave Newton
  • 158,873
  • 26
  • 254
  • 302
0

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...

Roger Johansson
  • 22,764
  • 18
  • 97
  • 193