So, it seems to me that you need to create a Service Oriented Architecture (SOA) in order to facilitate seamless communication for these three different
modules (User and Permission management, Projects, and Financing) kind of like what Amazon did and I would also be looking into creating that app as
a Multi-Tenant application. That way, you can point each main part of the app to a sub-domain, but maintain only a single copy of that application, which in
turn sort of brings down the complexity level a bit for testing. Turning your application into a Software as a Service (SaaS) can prove to be beneficial, but on
the flip side it may not be what you want, so be sure to research the pros and cons to see how best it fits your needs.
The next important thing that you should consider is how your storing the data, meaning if you want to go with a relational database or a No-SQL datastore. I
assume that you are already using a relational database, so migrating to something else at this time will be tremendous work given the size of the app now.
For example, PostgreSQL a popular opensource RDBMS allows you to store schema-less data using Hstore. You could for example, define scopes
to limit or restrict certain data and fields based on which sub-domain your on.
Also, as Reuben suggested, try to find those parts of the current app that intersects and build them out into a plugin, so you can share them across domains
and when you add a new feature(s) or re-factor some existing feature(s) all the apps gets updated, given that composer is what you are using to manage these
packages; nonetheless, it shouldn't be a problem updating features.
In the end, there are many ways you could go about doing this, but I suggest that you look into SOA and Multi-Tenant applications. Here is a small case
On Monday, 29 July 2013 12:48:48 UTC-4, Diogo FC Patrao wrote:
HelloIn my company, we develop software with cakephp for internal usage. The software is getting big for managing it as a single project (46 controllers, 94 models), and we've been thinking about splitting it in two or three different software, each to manage one different domain of the big picture (like, a system for user and permission management, other for projects, other for financing).However, there is the need for those modules keep comunicating. For instance, a report will need to get for all projects belonging to user X the current balance - That would need at least three models in three different modules. If I would be working with three different and independent cakephp, either I need to (1) get a copy of models from the other software, or (2) communicate via webservices.(1) is faster, however, I'll have a huge number of models anyway. Not to mention, as business rules are in the models, when one is updated, it must be copied to the other systems, causing a maintenance nightmare.(2) is ideal as it really encapsulate responsabilities, however it is slow. For instance, if I make a find on model Projects, each having a list of people linked to it, I'd like to bind those models. As far as I know, there's no Webservice Datasource, so I'll need to do it by hand.I'd rather (3) have everything deployed in one big cakephp installation, but maintain my repositories apart; however it would difficult testing. But I guess that, when working with big problems like that, you really have to face some difficulties.What are your thoughts on that problem?Thanks!
Like Us on FaceBook https://www.facebook.com/CakePHP
Find us on Twitter http://twitter.com/CakePHP
---
You received this message because you are subscribed to the Google Groups "CakePHP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cake-php+unsubscribe@googlegroups.com.
To post to this group, send email to cake-php@googlegroups.com.
Visit this group at http://groups.google.com/group/cake-php.
For more options, visit https://groups.google.com/groups/opt_out.
No comments:
Post a Comment