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?