Need to make an architectural decision on the project...?

Question

PHP

Hello! Dear habra community, you need to make an architectural decision on the project, but there is not enough experience. If someone developed the architecture of the project, I will be grateful for your advice!
There is a project:
- One page application. Written in Javascript: Backbone.js, jQuery, Underscore.js.
— The server part is written in PHP. The CodeIgniter framework is used as a router.
- The administrative part is written in CodeIgniter using Twitter Bootstrap.
- Self-written core (Core). The main logic of the project is concentrated here. Core is divided into modules. The kernel registers and calls all modules. Each module includes code that performs certain actions on objects (logical parts of the project). Each module is divided into Writer and Builder. Writer writes information to a MySQL database. The Builder gets information about the object from the database. A driver is passed to each module from the kernel to work with the database. There is also a logger for logging all actions. Thus, a driver and a logger for different databases can be passed to each module.
Have questions:
1. Modules have only a set of functions for writing or taking information for a specific object (they work directly with MySQL), but there should have been an ORM ... Through this there are duplicate functions. Perhaps modules should work with the DataMapper pattern? What can be done? Modules must return or store an object with a set of fields in order to pass this JSON object to JavaScript.
2. The project is launched for several countries. One code is used for both projects, but there are some differences in functionality (for example, a ZIP code is only needed in 1 country). Different functionality works in such a way that in PHP you need to set "IF" by country identifier, which breaks the code structure. How can it be solved?
3. Does it make sense to connect Doctrine to work with the database?
Thank you!

Answer 1

Right now you've heard a lot of architectural solutions and get even more confused =) How many people, so many decisions!
But based on my experience, I can advise you to do a couple of things:
1. do not invent anything superfluous and do not complicate the code
2. if the project is long-term, you will still refactor, so do a weak link, then it will be easier to edit in small pieces
3. if not a lot of time, use those tools that you know better, even if there are 100 times cooler and the whole world advises them =)
There are no clear and global architectural solutions.

Answer 2

1. Projects loaded? Then why ORM? Guzzle memory, eat time, less flexible. On the contrary, people try to switch to HandlerSocket under heavy loads. Uploading to json, I don't see any problems. json_encode does the job just fine.
2. In the git as separate branches. There is, for example, a master branch, there is galulu, for the country of galulu. We'll have to merge, but without extra code. You can do it automatically.
3. Again, depending on what you want to achieve in the end. Security due to slow operation? Security can be achieved in other ways

Answer 3

1. It's hard to say which is better. But you can try to compare. We have onPHP with our own ORM. ORM is convenient in that forms with field rules can be automatically generated from entities. As a result, importing data from the front-end comes down to importing into a form, validation (you can also add custom check rules), filling an ORM object with a form and a save method. Exporting an object is, in general, obvious to the point of disgrace.
How much such a mechanism is simpler or more difficult - think for yourself. But as I understand it, the use of such technology will force a major rewrite of the core.
2. No patterns fit? For example strategy.
3. See point 1.
I may not quite understand yet, but why log exactly all actions, especially if it is at the database level?

Answer 4

1. Contrary to popular belief, it is not the ORM that "slows down" the database, but its inept use. Here is a report on this topic in relation to Doctrine, and here are slides from the report.
2. I agree with @kryoz about the Strategy pattern.
3. You need to weigh all the pros and cons, taking into account the arguments from the first paragraph.