CODEWITHSUNDEEP
oopdesign-patternsarchitecture
ssharma
ssharma

Reputation: 541

Need help in selecting the right design pattern

We are into the lead business. We capture leads and pass it on to the clients based on some rules. integration to each client very in nature like nature of the API and in some cases, data mapping is also required. We perform the following steps in order to route leads to the client.

  1. Select the client
  2. Check if any client-specific mapping(master data) is required.
  3. Send Lead to nearest available dealer(optional step)
  4. Call client api to send lead
  5. Update push status of the lead to database

Note that some of the steps can be optional.

Which design pattern would be suitable to solve this problem. The motive is to simplify integration to each client.

Upvotes: 0

Views: 77

Answers (3)

Goose
Goose

Reputation: 546

Sounds like this falls in the workflow realm. If you're on Amazon Web Services, there's SWF, otherwise, there's a lot of workflow solutions out there for your favorite programming language.

Upvotes: 0

Gul Ershad
Gul Ershad

Reputation: 1771

I will divide your problem statement into three parts mentioned below:

1) Integration of API with different clients. 2) Perfom some steps in order to route leads to the client. 3) Update push status of the lead to database.

Design patterns involved in above three parts:

1) Integration of API with different clients - Integration to each client vary in nature like the nature of the API. It seems you have incompitable type of interface so, you should design this section by using "Adapter Design Pattern".

2) Perform some steps in order to route leads to the client- You have different steps of execution. Next step is based on the previous steps. So, you should design this section by using "State Design Pattern".

3) Update push status of the lead to database: This statement shows that you want to notify your database whenever push status of the lead happens so that information will be updated into database. So, you should design this section by using "Observer Design Pattern".

Upvotes: 0

Gerry Mantha
Gerry Mantha

Reputation: 1098

You'll want to isolate (and preferably externalize) the aspects that differ between clients, like the data mapping and API, and generalize as much as possible. One possible force to consider is how easily new clients and their APIs can be accommodated in the future.

I assume you have a lot of clients, and a database or other persistent mechanism that holds this client list, so data-driven routing logic that maps leads to clients shouldn't be a problem. The application itself should be as "dumb" as possible.

Data mapping is often easily described with meta-data, and also easily data-driven. Mapping meta-data is client specific, so it could easily be kept in your database associated with each client in XML or some other format. If the transformations to leads necessary to conform to specific APIs are very complex, the logic could be isolated through the use of a strategy pattern, with the specific strategy selected according to the target client. If an extremely large number of clients and APIs need to be accommodated, I'd bend over backwards to make the API data-driven as well. If you have just a few client types (say less than 20), I'd employ some distributed asynchronicity, and just have my application publish the lead and client info to a topic corresponding to client-type, and have subscribed external processors specific for each client-type do their thing and publish the results on another single queue. A consumer listing to the results queue would update the database.

Upvotes: 1

Related Questions