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.
1
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.
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.