Modular architecture by examples..?

Question

PHP

Actually, I set out to finish my bike in the form of a microframework. The task is to implement a modular application architecture. That is, the main application - and many many modules that are not limited in nesting. Moreover, the application itself, in fact, is also a module ... I
came across the development of a modular system only when working with YII, but according to some, using a cascade file system greatly simplifies (or just comes out more concisely) development.
In connection with this question. Can anyone provide (based of course on personal opinions about this issue) the most convenient implementation option, or indicate the direction of the search for this implementation ...
Much appreciated.

Answer 1

I made my framework based on events. In the core, with each sneeze, an event is generated, add-ons use this, if they wish, they generate their own. Convenient, not expensive, fast and easy. The disadvantage is that during the event, only that part of the application that you were given is visible.
When using a cascade file system, there are also advantages, but it's slower, whatever one may say, and scanning fs and searching for files takes a long time.
There are still options with registering components in the kernel and then the kernel calls them itself, but I have not worked with such things, it seems to me that this is not critical.

Answer 2

I will answer as a user of the Kohana framework (with the same CFS).
The project has conditional folders Application, System and Modules (naturally, the names can be anything). System stores the core code of the framework (basic classes for routing, MVC/HMVC, helpers, etc.). Modules has a bunch of plug-ins, both standard (Database, ORM, Cache, etc.) and in-house developments. Well, in Application there is code specific to this application (that is, which you do not plan to transfer to other applications).
Any module used must be explicitly declared in the system ( Kohana::modules($module_list)). When adding a module (or a list of modules), the following algorithm occurs:
0. The main class of the module has a static variable $_paths, which stores all CFS paths. Initially, the path to Application is added to it.
1. The path to the module is checked, if not, the module is ignored.
2. The module is added to $_path. A check is made for the existence of the init.php file in the root of the module. If it exists, then it is executed. Thus, it is possible to carry out some initial actions (loading configs, adding routing, etc.).
3. System is added last to the list.
The structure of files and folders is the same, in Application, in System, in each module. After lining up the list of paths in a row, we get the opportunity to go through it in search of the desired class. For example, if there are modules A, B, C, and B and C have the class Foo, then the system will select the class from module B, since it comes first in the path list. The precedence is affected by the order in which the classes are mentioned in the invocation list Kohana::modules(). The paths are regenerated every time it is started, but the search results for files are cached in order to less rustle on the screw.
To understand such a structure, it is very useful to look at this picture . As a result, the project itself (Application) often consists of configs and a startup file (bootstrap), everything else is taken out into modules.
In addition, the flexibility and extensibility of the framework is achieved through "empty" classes, for example, there are Database and Kohana_Database (extends Database). All the original functionality is implemented in Kohana_Database, but in the code we use Database. Accordingly, you can add your own Database class somewhere in Application or in one of the modules (in this case, the system will load it, and not the analogue from System), and make the necessary changes in it.
PS. And events are still a handy thing (albeit quite simple - Event::add()and Event::run()). They are no longer standard in Kohana v3 (because there is sufficient control over the execution of the Request), so you have to manually fasten it for your own events.