Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've worked for a number of companies that have, over time, branched out their core service to provide additional services and/or revenue streams. My question is when is the proper time to separate these concerns into multiple applications, even when they're operating on the same/extensions-of-some data?

For example, say a company has a core business application that resolves around a music index/music discovery. If this company later decided to branch out into offering websites for musicians that utilize their existing index, should this be a separate application that receives its data from the core-business-application via API, or is it reasonable to lump this into a module of the existing application, and use existing business objects?

It seems to me that the ability to lump things into one application shouldn't be reason enough to do so. In Unix, we practice Separation of Concerns, but when it comes to enterprise development, this principal seems to be lost. In the example above, I would feel that these should be separate applications, but in my experience I witness developers lump these together to save time.

share|improve this question
This happens a lot. If you're looking at a new possible source of revenue - don't spend the time and money to build out separate servers, just lump it all together. For example, I was working on one project that was a CMS into which they'd built an instant messaging system. And other than some shared users, they had nothing to do with each other. Over time this resulted in tortured code where the two concerns tripped over each other. Short term savings, long term pain. – ipaul Mar 17 '13 at 14:45

I think it boils down to whether or not there is any sense in bundling the functionality as an addon/extension or if it should be standalone on its own right. In your example, it would make more sense to me to expose the relevant data in an SOA manner for the musician websites rather than bolting it onto the core application as there is practically no overlap other than data. Relevant logic would be encapsulated in the services.

Generally I think practicing a separation of concerns is the best bet, modularizing applications and reusing code wherever possible. A prime example of this would be Microsoft Office, which leverages a (fairly) consistent interface provided by various shared libraries, shared spell checkers, VBA, and more whilst implementing their own core logic and interface.

share|improve this answer

The proper time is now, unless you have other requirements to fulfill. The more separated the layers of your application are, the more flexible it will be to adapt to changing requirements. Whether it makes sense to implement a layer as an API or as a service depends on your requirements.

I can not guess as to why more developers do not take the Separation of Concerns principle more seriously. Perhaps they do not see the long benefits out weighing the need to get the job done now.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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