0

I'm trying to figure out how to structure a 3rd party integration microservice, and how to name the classes accordingly. If you had a classic shopping cart application which processed payments for different credit card vendors(Visa, Mastercard, etc), this would be for a credit card microservice for exactly one vendor.

The microservice should read a charge from a message bus and then send a request to the vendor to charge the card. Within a Visa microservice I would have:

  • CreditCardChargeHandler - Read the message(includes credit card info) from the message bus
  • SettingsService - Makes http calls to get settings
  • VisaService - Makes external http calls to actual Visa
  • Visa - This is the class, that seems the most unclear to me
    • It has a Charge method that takes in the credit card
    • Calls SettingsService to get the needed settings to be able to call Visa
    • Calls VisaService
    • Could also contain other methods like Authorize, Refund, etc

I wasn't sure if the Visa class should be called Visa since it's not actually Visa but it sort of is my representation of it. Other names I could think of were CreditCardProvider but that's really generic. Also, Visa is where all the real code is but is it doing too much? I've seen examples where people would have CreditCardChargeHandler do all the work but that doesn't seem very object oriented. How have other people handled this that they keep it object-oriented but keep their classes from doing too much?

4
  • @DocBrown, the abstraction from the vendor would be that the front-end puts a message in the message bus, then there's 1 microservice for each vendor listening to the message bus for a credit card message for it's card type(Visa, MasterCard, etc).
    – Belaroth
    Feb 26 at 19:52
  • 1
    I took the freedom and edited your question to bring it in line with your comment. Please double-check that this is still the question you wanted to ask.
    – Doc Brown
    Feb 26 at 22:13
  • 1
    I removed my answer for right now. Thanks for the clarifications on your question. I might post an answer later. Feb 27 at 14:35
  • I posted a different answer in resisting to the edits. Feb 27 at 14:50
0

The Visa class is not doing too much. It is coordinating and delegating to specialized classes that handle specific parts of a Visa credit card transaction — this actually feels like a good name.

The name "Visa" to me represents the entire thing we know as Visa, not just the credit card part. It feels like a name for the whole company and all the operations it supports. I would also expect a method called "ApplyForCreditCard" or "GetJobListing" for a list of available jobs they are hiring for. "Visa" is just too generic for your use case.

If this class really just handles the gritty details of processing a Visa card transaction, then name it as such: VisaCreditCardTransaction.

It makes perfect sense to me for the control flow to go:

  1. Message
  2. CreditCardChargeHandler
  3. VisaCreditCardTransaction
    • VisaSettings
    • VisaService

This decouples the micro service message handling from the process of charging a Visa card. This also reduces the dependencies required for the VisaCreditCardTransaction class, since it should only need a SettingsService and VisaService passed to it's constructors. As long as both of those objects are interfaces, it should make VisaCreditCardTransaction easier to unit test — a pretty essential thing for a financial application.

1
  • 1
    Greg, thanks for your reply. I think most of your points make sense to me. I disagree with the name VisaCreditCardTransaction, a transaction suggests one specific interaction between the card holder and the merchant. The VisaCreditCardTransaction class could be used to create multiple transactions. What about calling it something like VisaCreditCardProvider?
    – Belaroth
    Feb 28 at 13:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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