Multiple APIs v One API

Question

Is it normal to have a bounded context spread accross multiple APIs or should there really be one API per bounded context?

I am trying to understand if I can use the Scatter Gatherer pattern (https://www.enterpriseintegrationpatterns.com/patterns/messaging/BroadcastAggregate.html) in a hobby application I am developing to improve my knowledge of DDD.

Multiple APIs - Use scatter gatherer

The example I have posted is for a mortgage application where a quote request is broadcasted to multiple vendors and then once a suitable amount of quotes is received then the aggregator chooses the best quote.

In this scenario it appears that there is a bounded context spread accross multiple APIs. The solution structure will look something like this:

The solution structure will look something like this:

Offers.API //Contains the aggregator
Offer1.API
Offer2.API
Offer3.API

The domain model in the Offers.API will look something like this:

public class Customer
{
   public string Name {get; set; }
   public DateTime DateOfBirth {get; set; }
   public List<Offer> Offers {get; set; }

   public void AssignOffer(Offer offer)
   {
    Offers.Add(offer);
   }
}

The Offers are passed to the AssignOffer by the aggregator. The Offer class will be anemic in the Offers.API because the domain logic is contained in the other APIs.

I believe the benefit of this approach is that it is more configurable. Every time a new offer is added then a new API can be created.

Single API

Instead I could just have one API and map offers from the database to classes using Table Per Hierarchy mappings. Every new offer added will require the application to be compiled and published.

Answer 1

From an architectural standpoint, what you are talking about is probably more commonplace than you may realize. Essentially, there are multiple reasons for having multiple instances of APIs. In fact, it's kind of what Microservices are.

Reasons for multiple APIs:

• The APIs are hosted by your providers (in this case mortgage lenders) and you are consuming them
• You need to dynamically scale to handle load for a portion of your application
• You are sharding data across multiple nodes (like most NOSQL data stores)
• You are implementing your system using microservices

Your problem is essentially an aggregated search problem. You make an asynchronous request to multiple providers and when you collect enough results, you start prioritizing and sorting the results.

To answer your question, yes it is normal to have several microservices (small APIs) working together in a solution. It's a valid design decision, but the flexibility you get from microservices does come at a price.

• Microservices are more complex to develop, test and deploy
• They allow you to spin up additional copies of services to handle demand and then get rid of the excess services when they are no longer needed
• When combined with Single Page Applications (SPA) you can keep track of sessions on the client so you don't have to manage that on the server, reducing the intercommunication needed somewhat

You'll find that most well known applications that handle a large amount of concurrent users are built using a microservice architecture, so it scales well. However, most of those applications also started out a lot more simply and evolved that way over time. If this is for your personal learning, I would recommend getting familiar with microservice architecture. If this is for a real project, I would recommend starting with an approach your team already understands and potentially migrating to microservices if you start getting close to the level of traffic that would mandate that approach.