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.


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.

  • This is the best balance of changeability and practicality. Thanks for your response. – Jesse Bunch Aug 31 '12 at 14:00

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.

  • This is a really good answer, but it's little over the top for this specific use-case. +1 for showing me another way to do it. – Jesse Bunch Aug 31 '12 at 13:59

I think that you are on the right trail as far as separating the logic and actions to be performed on these services. Jgauffin is correct in stating that you should give the "integrators" a better naming convention. i_objectName_whatObjectDoes is a good start and makes it much easier for future developers to know what object does what function.

When it comes to code separation, you might want to look in to making use of DTO's, Data-layers, and Object Managers. This makes your solution more readable. Remember to keep your DTO's, Datalayers and Managers in sepaerate projects and include them in your solution.

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.