I am trying to follow a layered architecture, with a DDD approach.
In my Application layer I am putting both DTO request and response. Let me explain:
1- CreatePostRequestDto, this object is created in the Presentation layer that is sent to the Application layer, to my CreatePost service.
2- PostResponseDTO, this I have it in the Application layer as the previous object, this object is created in the Application layer in the CreatePost service, and it is passed to the Presentation layer and where is the Controller that is in responsible for serializing it to JSON.
I don't know if I'm doing it right, as I'm getting a bit confused because I've seen other meanings of these DTOs like View Models, and it seems that these are placed in the Presentation layer instead of Application, which is different to how I'm doing it.
So, if for example I create a ViewModels directory in my Presentation layer, PostApiViewModel, this DTO would be only for this case, right? I should still have my DTO PostResponseDTO, to pass the data from my Application layer to my Presentation layer (Controller), and then in the controller convert my PostResponseDTO to PostApiViewModel, no?
Every layer in your application should be only working with its own models and be transferring them if it passes data to another layer. You can think about this approach like building microservices. Every layer has got its own API which should be followed.
In classic layered architecture, you would use ViewModels for presentation layer, DTOs for bussiness logic layer and Entities for repository layer (also called domain layer). DDD approach gets rid of bussiness logic layer.
That means it is well suited for applications which mostly rely on very basic Read/Write operations. If that is your case, then there is no problem just returning plain domain models from your Controller without any DTO transformation. You can then transfer your domain model into ViewModel in the presentation layer if necessary.
For an example - if you want to display table of pure database data, then there is no need for that transformation. If you want to display some of the calculated fields, then you should either make a column in database (and calculate them when inserting) or transfer your object into ViewModel, which should be able to calculate them so you can just display them from the ViewModel.
With DDD approach, when writing data, you should be creating straight up domain models, which then will be sent to backend, so it can store them directly. Here comes the same rule as when reading them. If you need additional calculations to your fields, you can first create ViewModel (typically from form) and then transfer it into domain model when passing to backend.
Typically, your bussiness logic layer would be responsible for these calculations but it is not always necessary to build a whole new layer to calculate one field in one object. When you are deciding whether go for the classic layered architecture or DDD, you should think of the calculations in your fields, that will be necessary. If you find a lot of them before building your application, then it's not the best idea to go for DDD because that would mean a lot of bussiness logic in your presentation layer (ViewModels), which is never a good practice. However, if there are few of the calculation that need to be done (for an example not calling an external API, but just calculating a + b), then there is no problem doing that in a ViewModel.
Hope this helps