1

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.

  • I would think you want runtime configurable for adding/removing external vendors. – Erik Eidt Jan 23 at 17:03
  • @Erik Eidt, runtime configurable means multiple api's. Is that right? Thanks. – w0051977 Jan 23 at 17:35
  • I would think so. – Erik Eidt Jan 23 at 17:55
  • @Erik Eidt, would you expect to see this for a single bounded context? If you could post an answer then that would be great else a comment would be good. – w0051977 Jan 23 at 17:56
  • @w0051977, Are your vendors hosting the APIs, or are they included through another mechanism? The main idea behind a federated search is that you can add new vendors just by updating a configuration. – Berin Loritsch Jan 23 at 18:51
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.

  • Thanks. I understand the Microservices architecture. However, I wander if there should be one microservice per bounded context? Is it normal to have a bounded context spread across multiple APIs like this? The Aggregate Roots are also spread across multiple APIs. +1 for the reference to Aggregate Search. – w0051977 Jan 24 at 9:23
  • @w0051977, like any design, you weigh your options and choose the most appropriate answer. DDD is a way to design your system from a logical perspective. How you draw your boundaries is up to you, but having multiple copies of a microservice in your system is fine. If a different configuration makes them logically different, that fits your bounded context model. When talking about design, don't confuse the logical services with service instances. There are runtime and deployment reasons for having multiple instances of any given service. – Berin Loritsch Jan 24 at 15:08
  • the other concern I have is that the Offer class in the Offers.API will be anemic because all the domain logic for Offers is distributed across the APIs. Does that make sense? Does that make sense or am I missing something? – w0051977 Jan 24 at 17:25
  • @w0051977, wouldn't that central Offers API be your Offers Aggregator? The domain logic for each provider will be unique to that provider. The only thing left is to aggregate and decide which offers to present. That may not be as anemic as you are thinking over time. Particularly if you incorporate some machine learning to suggest the best match for the user. – Berin Loritsch Jan 24 at 17:32
  • Could you explain how machine learning could be applied here? As stated it is more of a learning application. – w0051977 Jan 24 at 17:38

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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