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.

  • why downvote? please comment at least
    – Question3r
    Feb 16, 2020 at 19:02
  • A choice for an architecture depends on what problem you're trying to solve. There is no problem defined here. But here goes a general advice: take a look at "simple architecture" from Bob Martin; your "core" application or architecture, should not depend on Web, or the DB technology you're using (they should be 'pluggable' to your core application -- that is, your business rules). Feb 18, 2020 at 18:09
  • thanks, then I would say having one interface for requests and one interface for responses per layer should be the right way ...
    – Question3r
    Feb 18, 2020 at 18:19
  • Hmmm I would say not for Clean Architecture. In my experience: Having an own class for input and output for use cases works well, but you don't need an interface, because they should be pure data classes anyway - you can "mock" them by just filling in the values. And the interface of classes in the Interface adapters layer, you can usually make them work with just primitives.
    – R. Schmitz
    Feb 18, 2020 at 21:03
  • It is not really clear what your question is. Are you asking us what your architecture should be? You haven't shared anything about the software you are writing.
    – Helena
    Feb 18, 2020 at 22:12

1 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.