Where to place "Backend for Frontend" logic in a DDD system

Question

Assume I have a simple system with two (simplified) domains in the backend where the Root aggregates are the following, simplified ones:

• Product with product_id and description
• Warehouse with a warehouse_id, warehouse_name and Map<product_id, amount>

The system is a modular monolith where each domain is a separate, isolated module. Every module/domain has HTTP endpoints to retrieve and manipulate their main entity.

The requirement is to display a list on the website, the only frontend to the system right now, which looks like this:

Product    |  Amount in Warehouses        |
-----------|------------------------------|-------
Product 1  |  Seattle: 32, Baltimore: 17  | Save
Product 2  |  Seattle:  0, Baltimore: 21  | Save
...

In addition to just displaying the values the "Product" field and the "amount per warehouse" field are editable. Also, the list should be sortable and filterable, e.g. by amount per warehouse or product name.

I have a few questions related to the interaction and the placement of HTTP endpoints that will be used by the frontend application.

1. Where to place an endpoint that retrieves this whole list, including data from different domains and handling the filtering logic?
2. Should this actually be a dedicated endpoint or should all logic be done in the frontend, assembling the data as needed? Should the frontend even know about all the different domains/modules?
3. Does it make sense to create a dedicated "Backend for Frontend" module that provides all URLs, handles the authentication, etc., and manages the complete "application" logic?

I tried finding a similar question here for the past hour, but I couldn't find one which tackles this exact issue.

Answer 1

I think this question can be simplified down to "Do I need a 'backend for front end'?" DDD doesn't really add any more restrictions over other architectures.

In these senarios you have 3 options

1. Make a new API which returns the composite data

   This can be useful if the composite is something that is reused in multiple applications. However from a DDD perspective you would question if this composite object was its own Domain Object, or if you had structured your other domains correctly. You should ensure that the returned objects are treated as proper Domain Objects, have a well defined responsibility and don't change often.

2. Have the front end call the various APIs directly and assemble the composite itself

   With javascript SPAs becoming more and more complex and able to handle more logic separated from the pure view logic, this should be your default option. Holding the underlying data locally on the client allows it to be cached and reused in multiple Views without a round trip to the server.

3. Add a new API which is part of the front end app and wont be used by other apps. It should only return ViewModels for the front end.

   The assembly logic may be complicated for the front end, or you may want not to allow end users to call the APIs direct, or add caching, or some other logic where a backend is required or just makes thing easier. A "backend for frontend" is what this kind of API is called, we don't have to worry about the objects it returns being part of a Domain, or having encapsulated responsibilities, they are simply ViewModels for the front end and change when the front end changes. Because of this they should not be used by more than one application!