I might suggest usage of plugins, and perhaps composer. I'm not sure if you're talking about physical domains, when it comes to the split (as in there's one URL for users and permissions, another for projects and another for financing). Lets assume you do, and address the alternative later on.
So, with three domains, that's possibly 3 applications, and those applications just include the plugins that are relevant for the app to run. Some apps may share the same plugin, so use composer to source the plugins from a single location. There's a fair bit of refactoring in there, so you'd want to think about it very carefully. Now, the alternative, it's still the single domain, but you just want to split the source up. I'd still suggest plugins. Find a handful of controllers and models that work tightly together and isolate them in their own plugin. Conceivably, you could drop that plugin to any other project and use it. There may be a dependency tree on other plugins. And you could still use composer to help manage including specific versions of the plugins into the single app. I'd be excited to consider usage of namespaces to aid with the split. It's not something that I've dived into yet with PHP, and I'll be waiting until CakePHP 3.0 before I do. Not sure what you're using for source control, but I'd shy away from git submodules. For the few dealings that I've had with them, they seem to introduce more problems that they're worth. My 2c on large systems with shared components. Regards Reuben Helms On Tuesday, 30 July 2013 02:48:48 UTC+10, Diogo FC Patrao wrote: > > Hello > > In 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/cake-php. For more options, visit https://groups.google.com/groups/opt_out.
