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.

  • You may want to review what Udi Dahan has written about composite UIs. Here's a starting point: udidahan.com/2012/06/23/… Nov 27, 2022 at 13:27
  • Thank you for the link. It basically says "move all logic into the frontend". What if the logic is complex and it would result in quite many requests to the backends? Where would you place the aggregating endpoint? In one of the domains?
    – DaDaDom
    Nov 27, 2022 at 19:49

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

  • Thanks. In 2., how would it work for the "filter and sort" usecase? Would the SPA/Frontend App determine which domain to query first and then call them in the correct order? E.g. "If sort by amount then first query from warehouse domain, then fetch the corresponding product names by id from the product domain" and "if find by product name, call the 'find by name' endpoint of the product domain and enrich with the warehouse data afterwards"?
    – DaDaDom
    Nov 27, 2022 at 19:36
  • query for everything and store to local storage/zipped cookies. do sorting and filtering in memory
    – Ewan
    Dec 8, 2022 at 17:56
  • Querying everything is not really an option due to performance reasons. We don't want a mobile phone to download a few MBs just to show 10 lines of some information.
    – DaDaDom
    Dec 9, 2022 at 14:48
  • Obviously without the full info I cant optimise your application for you. What I'm saying is, often, yes you do.
    – Ewan
    Dec 9, 2022 at 19:30
  • Sorry @ewan, my intention was not to dismiss your comment, but as I said that is not an option. We did do it like this but the amount of data in combination with our users' technical setup resulted in the issue in the first place.
    – DaDaDom
    Dec 10, 2022 at 9:28

Your Answer

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

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