M
M
Muhammad2015-11-13 20:19:16
PHP
Muhammad, 2015-11-13 20:19:16

Modularity of a php application (on the example of an online store)?

For example, there is an engine for an online store (blog, forum, whatever). It has the following modules:
Catalog - in fact, the product catalog itself
Cart - shopping cart
Order - module for ordering goods
Pages - information pages
Payment - module for working with the API of various payment systems
Search - product search
Users - registration/authorization
Wishlist - user wish list
Purpose :
Full control of the store. Would you like to make a catalog of goods from the store? Just disable the registration module and the order module. Or, for example, a "simpler" store: we leave the module of the catalog, basket and ordering goods.
There are following problems:
1. Dependence of modules from each other.
Simple example:
Cart depends on Order , Order in turn depends on Payment . At the same time, neither Order nor Payment can work without Cart (unless you order a product in one click). Alternatively, you can write module dependencies in a separate file (something like composer.json) and disable/remove dependent modules when you disable/remove the module they depend on.
2. Problems with the interface (layout, themes)
Main problem. Disabled registration (basket, search) - you need to remove the links in the header. So the layout can fly. Or the theme does not support the required module.
Questions:
1. Is it possible? If not complete, then at least a weak dependence of the modules on each other?
2. Is it worth it?
3. What are the ways to reduce the dependence of modules on each other? Only the event model comes to my mind.

Answer the question

In order to leave comments, you need to log in

2 answer(s)
S
Sergey, 2015-11-13
@muhammad_97

At the same time, neither Order nor Payment can work without Cart

So you have a cyclic dependency between Order and Cart? I understand so?
In general, Order, Cart and Payment can be combined into one module that defines the basic interfaces + a thousand modules with the implementation of interfaces. Like CardPayment, etc. In a word, you need to get rid of cyclic dependencies and think about cases when it will work with something. Let's say Cart without Order doesn't make sense, but Order without Payment does.
It's a good idea that a theme should contain metadata about which modules it supports and which it doesn't. + idea with widgets.
More than that, you just have to split the system not into such modules but into separate components, use the principles of single responsibility, interface segregation and dependency inversion to the fullest .... in short, you will kill a lot of time, but it is possible.
Alas, you alone will not be able to write and maintain such a system. Many have tried and there are even a couple of good options ( sylius.org for example), but alone in a reasonable time is unlikely.
Domain events are, by the way, a good option for reducing connectivity, and can be considered as an option. But in general, compliance with the SOLID principles and a more rational division of functionality, the search for common dependencies, and so on should be enough. Interface Segregation + Dependency Inversion.

E
evnuh, 2015-11-13
@evnuh

2. Not worth it.

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question