Reputation: 9183
I'm creating an entire website that will me a conglomeration of a bunch of smaller sites. Naturally they're all interrelated, but different people will log into different sections for different reasons.
One thing I'm trying to get away from is a a monolithic architecture, I like the idea of breaking up everything into subprojects so one team can work on one project, one team can work on another project, etc.
My question: I'm hearing more and more people doing interproject communications by way of restful APIs rather than having direct access to the database.
For instance:
app 4
|
app1 -----> central core <------app2
|
app 3
so apps 1-4 would communicate with a central core by way of APIs. They would have their own individual models for their own specific applications, but a central core would contain the bulk of the application.
My question: Is it correct implementation to go about this design, or should I just stick with the traditional monolithic project which contains one model implementation?
Where can I get examples of good system architecture?
Thanks
Upvotes: 1
Views: 76
Reputation: 1069
There is no doubt that abstracting the functionality into API is the right way to go to reduce the maintenance overhead. You should see a project like llvm.
The problem which comes with breaking your application into a "core" and a "driver" is, that the software upgrade gets a little tricky. Because now you have to upgrade both core and driver together. That is the biggest issue in shipping software as a library. If core is old and driver is new then it will not work.
But I do not think this is an issue for you.
THere are many good books on software design.
Upvotes: 1