Define input and output interfaces for each application layer

Question

I want to create a multi-layered backend architecture with a REST layer and GraphQL layer later on.

So let's say you would start with the basic layers controller, service, repository would it make sense to create request/response interfaces for each layer?

When creating a user you might come up with

• create-user DTO => controller request => holding username and password from the body
• user DTO => controller response => user object sent back to the client
• create-user BO => service request => request data coming from the controller
• user BO => service response => user object coming from the service
• create-user DAO => repository request => request data coming from the service
• user DAO => repository response => the database user

So each layer would define its own input and output data. Would this be considered best practise or are there any better ideas?

It would also be possible to create a separate library for each layer and the controller would consume the service library.

Answer 1

It says you are looking for a canonical answer, but I don't think there is one. I think parameter objects and DTOs are goodness because they tend to reduce coupling. But there is also a school of thought that data members and methods should live together. Furthermore, if you are striving for immutability, DTOs usually don't cut it because often the fields have to be writable. Along the same lines, it really depends on your stack. There is not a lot of resistance writing an object that came in via REST in a MEAN stack (MongoDB, Express.js, Angular, Node.js) to the database. It comes in as JSON and it gets written out as JSON. Whereas in .NET/SQL, you'd have actual translation layers that do work.

So, DTOs vs. passing fat objects down the stack, definitely. Blind adherence to creating all these layers and their own dedicated DTOs? They'd have to earn their keep through actually adding value.