I am applying DDD for the M part of my MVC and after some research (studying up!), I have come to the realization that I need my controller to be interacting with domain services (in the model). This would make my controller the consumer of the domain services and therefore an application service (in DDD terms). Is this accurate? Is there a difference between a controller and what DD defines as an application service?
Asked
Active
Viewed 1.2k times
4 Answers
16
The application layer is somewhere between the domain layer and the presentation layer. The controller is part of the presentation layer, sends commands or queries to the application layer, where the application services execute them using the services and objects of the domain model. So controllers are different from the application services, and they are probably bound to the actual communication form, e.g. HTTP. You should not call domain services from controllers directly, this might be a sign of misplaced code.
Domain Driven Design: Domain Service, Application Service
- Domain Services : Encapsulates business logic that doesn't naturally fit within a domain object, and are NOT typical CRUD operations - those would belong to a Repository.
- Application Services : Used by external consumers to talk to your system (think Web Services). If consumers need access to CRUD operations, they would be exposed here.
So your service is probably an application service and not a domain service, or some part app services, some part domain service. You should check and refactor your code. I guess after 4 years this does not matter, but I had the same thoughts by an application I am currently developing. This app might be too small to use DDD on it, so confusing controllers with app services is a sign of overengineering here.
It is an interesting question when to start add more layers. I think every app should start with some kind of domain model and adapters to connect to that domain model. So if the app is simple enough, adding more than 2 layers might be not necessary. But that's just a thought, I am not that experienced with DDD.
15
The controller is not considered a service in DDD. The controllers operate in the UI tier. The application services gets data from the DB, validates data, passes data to client (MVC could be a client but so could a request coming from a winforms app) etc etc.
All the controller is doing is servicing requests from the UI. Its not part of the application domain.
Greg
- 2,654
- 3
- 36
- 59
-
The controller services requests from the view by passing the request - or the pertinent part of it - to the Model. MVC is an architecture and definitely could be applied to winforms as well as web apps. I beg to differ regarding the position of the controller. The View is definitely the only UI-Layer and the point of MVC is to keep this UI-Layer separate from the controller. Your point is well taken though; thanks for the response. – Louis Sep 05 '13 at 18:16
-
4-1. Controllers are requests/commands coordinators. In a hexagonal architecture controllers are right above application services/command handlers/query handlers. Controllers is a request translator and is coupled with the communication protocol (upper layer) and the command/query handlers (application services from a lower level). Controllers can be viewd as application service facades because they translate and prepare the command/query/message to be process by the lower level layers (application service/command-query handlers). – Tudor Jun 26 '14 at 12:41
-
3-1 because controllers have nothing to do with DDD . It is irelevant where you put the controllers, you could say the controllers are just message/communication coordinators and they are coupled both ways : ui and application service. You could have controllers in a bounded context where there is no UI (a pure commanding context) . And you could have a bounded context just for presentation (a composite business component made up just for querying 2 or more bounded contexts). P.S. controllers have low coupling to UI, they just expect a set of request parameters no matter from where. – Tudor Jun 26 '14 at 12:46
6
In DDD Reference controllers are not mentioned at all. So I think from DDD POV the answer is undefined. So I would consider more practical question: "Do we need to separate Controllers and Application Service"?
Pros:
- Separating input processing from use case implementation.
Cons:
- Extra layer of indirection that complicates understanding of simpler cases. (It is also annoying to implement some trivial thing by pulling data though many layers without anything actually being done).
So I would choose separation of controller and application service if input processing obfuscates use case logic. I would choose to keep use case logic in controller if both are simple enough so that you can easily see in code use cases separately from input processing.
Alexey
- 9,197
- 5
- 64
- 76
5
A Layered Architecture splits the application up into UI-Layer, App-Layer, Domain Layer and Infrastructure Layer (Vaugn Vernons Implementing Domain-Driven Design (location 2901)). The controller falls in "Application Layer" of this broader design architecture and will therefore interact directly with the domain services in the model and is considered an application service. Not only that, it'll will obviously also use the entities and aggregates as available.
Louis
- 1,194
- 1
- 10
- 15
-
9If you look at pg. 72 of Evan's DDD you'll see that figure 4.1 shows the controller to be part of the UI layer. And that makes sense because if V and C would be in separate layers, you'd have intimate coupling between them when the layers should only be connected through indirection and interfaces. – Gordon Sep 10 '13 at 13:47
-
2@Louis, I haven't read Vaugn Vernons book but I have just come off a successful DDD project. All I can say is that the controllers were in a completely separate project, the client project. The client in our case was an MVC front end.It could have been any other client. The Application tier was a completely separate project that stood on its own two feet. It had its own validators and could serve out data through a WCF interface. The controllers in the MVC client merely called the proxy methods of the application layer. Other than that, they performed no other function. – Greg Sep 10 '13 at 14:43
-
@ Gordon V and C can be decoupled by using Passive views or Supervising controllers. For some applications, coupling them isn't necessarily a bad idea either. It depends very much on the specifics of the application being developed. In light of your reference to page 72 of Evans, I'll retract my answer since it seems there are other approaches that differ from mine. Thanks for the response. I wish we could get into a good discussion on SO without the risk of the question being closed as not constructive ;) – Louis Sep 10 '13 at 22:03
-
@Greg, You can definitely have a full MVC application as a client. That's what happens when you use a well designed application in the form of a DLL. The MVC isolates the function provided by that piece of code. My question intends to examine a lower layer of development. If you use DDD as part of an encompassing MVC architecture, the Controller would serve as the application tier. If you create a separate application tier, you will duplicate a lot of, if not all, the code in your Controller. In case of validators: If you are validating input, use the controller. If data, use the entity. – Louis Sep 10 '13 at 22:12
-
@Louis - yes this is gonna get shut down soon. As you correctly said, we had loads of duplicated code but that is what is to be expected when you build tiers that are completely independent of one another. Any sharing of code creates dependencies. We could not use the controllers for validation because the app could be potentially serving clients that had written their own interfaces to the system, so in that case we would have not control of client side validation. This is why validation had to be repeated in the application layer. – Greg Sep 11 '13 at 08:45
-
@Greg For example if you'd have a webservice or web api, which processes http requests, then what would you call the class(es), which transform the requests into commands, which can be processed by the application layer? Wouldn't it be better to validate most of the things by command creation? So you'd have to check only the type of the command in the app service. – inf3rno Feb 09 '17 at 00:46
-
@Gordon Could I ask if we consider the controllers in MVC as a part of the UI layer, then What's the application layer ? – Anyname Donotcare Sep 08 '18 at 11:33