Approach for "Backend for Frontend" service?

[thatguysimon]

Hi,
We're planning to implement a Backend-for-Frontend (BFF) for our SPA and I've been wondering what's the best approach to do that with Domain-Driven-Hexagon in mind.

Let's say my main 3 use cases for the BFF are:

1. API aggregation - assembling multiple responses from downstream services - Seems to fit the responsibility of a Query Handler.
2. Implementing the Token Handler Pattern - Should probably be done at the infrastructure layer.
3. Storing some state for UX-specific concerns (i.e - a "do not show again" checkbox, some ephemeral data persistence before its submission to an API, etc.).

I'm mostly wondering if the domain layer (and maybe even application layer?) even has a place in a BFF.

Do points 2 and 3 seem like they would need the Application Core at all or should we stick with just Interface Adapters that talk directly with the Infrastructure layer via DTOs?

Would love to hear your thoughts.
Thanks!

[Sairyss]

Hey,
If you don't have much complexity in your app, you don't need all those layers. DDD is great for backends that have a lot of business logic that you can encapsulate in your entities/aggregates, and other complexity that you can abstract by ports/adapters, layers, etc.

But I wouldn't recommend using it for BFFs. In typical BFFs your backend usually acts just like a glue between frontend and your database, with very little business logic, so I'd say you don't need all of the complexities of DDD architectures for a simple BFF.
For BFF I would recommend something straightforward, like typical MVC architecture or something like that. All you need is some router/controller, service, dtos, some ORM library and that's it. You can check my other repository for an example https://github.com/Sairyss/fullstack-starter-template , here backend is pretty simple, modules just include a router/service/dtos and that's it. That's all that most of typical fullstack applications and BFFs usually need.