0
votes
  • views can call controllers
  • controllers only talk to views and service layer (where the transactions are)
  • service layer has a series of calls to domain object(s) wrapped in a transaction
  • domain object contains the calls to dao layer.
  • dao layer populates domain objects and persists data.

But I can pass the domain object around the different layers to access data via getters, or do I have to use a dto - a cut down domain object containing data specific to views/use-cases. Passing domain objects around the layers seems to encourage breaking the rule that layers can only talk to the specified other layers. But on the other hand, that is the point of DDD ? If it is preferable to take data from the domain object and put into a dto, where should this take place, the controller ?

Domain-driven-design, am it doing it right

3

3 Answers

2
votes

Personally I always use View Models (DTOs for your View). This helps cut down the amount of data passed to your Views and avoids accidentally revealing secure data.

In theory the UI (or several UIs or web services) should plug on-top of your system. For example, if you were exposing your system via Web Services, you would probably also want to flatten and reduce the data in some way, to not create a dependency on your domain entities (so you can change them without breaking external systems) and again not expose any ids or sensitive data in your domain entities.

I guess this would apply to any development practice and not just DDD.

1
votes

you should put the domain next to all other layers since it should be 100% independent of everything else. hence you should be able to use it everywhere.

Services in DDD should only be used when two or more different root aggregates need to interact.

As for transactions, why don't you just use TransactionScope in the UI layer? It's still persistance ignorant.

I personally use the repositories directly in the UI (since the repository in DDD is a DB abstraction)

1
votes

While it is true that in a canonical layered architecture things should be as compartmentalized as possible, passing domain entities all the way to the UI seems acceptable to me, especially in simple applications where Presentation layer and Domain layer are on the same tier. It only requires the UI to have a reference to the Domain, which isn't that shocking (the other way around would actually be problematic).

Mark Seemann has a blog post with interesting thoughts on that issue, though I don't share all of his views.