My understanding of the application services are that they link between the domain and the user interface together. In other words, they serve the controller to perform operations on the domain.
I have the following project layout in my application:
My Service Interfaces
lies outside the Web UI
project. Then in the Web UI
Project I implement the services interfaces under Services
.
However this structure is a bit flawed and creates a circular dependency when we put this in practice. I tried to follow the architecture in this link: https://www.develop.com/onionarchitecture
For a given service, I want to pass in the view model, perform operations on the domain based on the view model, then return an updated view model. Is this approach wrong?
Is my understanding correct that the application service in essence take the view model as a parameter, update some details in the domain and view model if it needs and then returns a view model?
Or
Does the application service only deal with c# datatypes and domain models as a parameter and returns the same datatypes? In other words does not get or set any information in a view model. In fact does not know the view model exist.
I just need some clarification on what is the best approach from a strict DDD approach.
Answering your questions: Yes, you are right. For MVC application, you can design layer that takes and returns ViewModels and operate with Domain inside
Good example of solution structure is made by Dino Esposito here. I adopted my project to this structure and it became much clear. My opinion is that onion architecture is overcomplicated for small or medium projects.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With