Are BFF (Backend for Frontend) and DDD mutually exclusive?

Question

BFF pattern provides one API (for some frontend) which integrates all microservices.

In my case, I have BFF that additionally is responsible for user authentication. My BFF project uses Clean Architecture.

One of my microservices is Conversations service. It provides me information with who some user started chatting, messages they sent etc.

And problem occurs with integrating microservices using BFF which uses Clean Architecture because my BFF inter alia is responsible for authentication.

I have User domain entity, which may look like below:

public class User
{
    public string Id { get; set; }
    public string Name { get; set; }
    public AvatarUrl AvatarUrl { get; set; }
}

So I wanted to create endpoint in my BFF that retrieves user info from authenticated cookie. Seems simple. But wait. My BFF integrates microservices and I build chatting app, so the conversations to which user belongs is also user info.

So we need to consider what is domain of my BFF? Is restricted to what BFF do locally (authentication), or proxying is also domain (microservices)? I mean, shall my User contain also Conversations property (list of conversations)? Can the domain entity depend on external services?

Or maybe there is no domain for BFF (because it integrates microservices and do mostly nothing on its own) and DDD here is just redundant?

Answer 1

I always considered BFF a broken piece of software design.

Your BFF should actually be your domain model for the interface you design.

So the BFF does not only act as a transaction script calling and delegating business logic to others services. Imagine the following:

you have a client request to change the domain logic on the app you deliver, you will then do what, change the BFF AND the services which contains the business logic ? This is pure overhead, also i've seen developers put specific domain model in the BFF because it was specific to their application.

Better do all the DDD in the BFF, and if you need generic subdomain, they are good candidate to model as a generic/support bounded context.

I haven't really answer to the question because I struggled the same with BFF, my advice is to not use them instead write proper DDD Bounded Context with the interface layer being the REST Resource.

You still have the 4 layers, assuming you have an hexagonal architecture:

• application
• domain.model
• infrastructure
• resources (<- interface layer in the form of REST API)

In short, your BFF reside in the port adapter part under resources.