Question: So I'm really wanting to improve how I architect the software I code. I want to focus on maintainability and clean code. As you might guess, I've been reading a lot of resources on this topic and all it's doing is making it harder for me to settle on an architecture because I can never tell if my design is the one that the *more experienced programmer* would've chosen.

So I have these requirements:

* I should connect to one vendor and download form submissions from their API. We'll call them the `CompanyA`.
* I should then map those submissions to a schema fit for submitting to another vendor for integration with the email service provider. We'll call them the `CompanyB`.
* I should then submit those responses to the ESP (`CompanyB`) and then instruct the ESP to send that submitter an email.

So basically, I'm copying data from one web service to another and then performing an action at the latter web service.

I've identified a couple high-level services:

* The service that downloads data from `CompanyA`. I called this the `CompanyAIntegrator`.
* The service that submits the data to `CompanyB`. I called this `CompanyBIntegrator`.

So my questions are these:

1. Is this a good design? I've tried to separate the concerns and am planning to use the facade pattern to make the integrators interchangeable if the vendors change in the future.
2. Are my naming conventions accurate and meaningful to you (who knows nothing specific of the project)?
3. Now that I have these services, where should I do the work of taking output from the `CompanyAIntegrator` and getting it in the format for input to the `CompanyBIntegrator`? Is this OK to be done in `main()`?
4. Do you have any general pointers on how you'd code something like this? I imagine this scenario is common to us engineers---especially those working in agencies.

Thanks for any help you can give. Learning how to architect well is really mind-cluttering.

Answer: 
Keep it simple. Write well-modularized classes that separate concerns. Your class names are fine, and you have the right idea that the two “integrators” should have no knowledge of each other and a third class should make calls into them to do the work. You won’t do it in main() if it’s a web app, main isn’t even exposed. 

I wouldn’t bother with the facades. Even if the vendors are replaced, the new vendors won’t have API’s, schemas and email providers that necessarily provide you with a clean mapping to your facade or interface. So you'd be making your client code write to an abstract layer, which isn’t needed now (premature optimization), and which you likely will have to rewrite in the future in any case.
imho the names are not good. What do `CompanyBIntegrator` tell you? that it's an integration. But does it tell you what the integration does? No.

`IYourEntityDownloader` or something like that is better. It tells you what it does.

As for the process, I would do something like this (soc):

1. Have a job that download the information and store it in a data store (db, flat file, memory etc)
2. Have a job that processes the information according to your business rules and then store the result in another data store
3. Have a job that takes the processed information and upload it to company b.

By having those three steps you can expend each separate step as much as you like without affecting the other parts. You could even use three different servers (or hundreds for that matter) .

You can also start downloading information from one source but upload to five destinations. The other parts would be unaware of that too since they have clear responsibilities.