A module is a set of methods for handling a data object.

As explained on the page Standards, helPHP follows a "variant set" logic, which are a bit like Russian dolls nestled together.
A large set contains smaller ones, until one reaches a single variable.
Today the concepts of object data are widely used, which is roughly the same without the logic of interlocking.

Let's say it by example:

You have a customer who is a car salesman, and you want to create an application to manage his used car inventory.
The car is a data object, but more precisely a set composed of a name, a description, a price perhaps and associated with smaller objects associated with it as a caracteristic.
For example the "rim" object, which has a name, a description too, a size, a type of alloy, a model etc...
Or the "body" : name, description, material (carbon, aluminum, composite etc...) ...
The "rim" and "body" object are also separate objects that could be associated with something other than a car, a motorhome for example that must be associated with different objects of a car (kitchen, sleeping table, etc.).

Because yes, we will have to manage the associations between these objects. When the association is unique, simply add the ID of the object associated with the other object, but often it is necessary to create tables of associations for technical reasons at the database level, but also to facilitate multiple links (if an object can be linked to different object types or to the same object several times).

A module therefore contains what will allow to manage a data set/object and its associations.
And it is often better to make several small modules than one huge one that will have to manage multiple objects at a time, except in cases where other objects cannot be used elsewhere (which is rare).

Note: In general, an object that will often be associated with others will see its module enriched with methods to manipulate its association quickly in other modules, such as for example the "widget" method of the "category" module which will allow to create sorting categories for several objects, thus avoiding creating too many modules to handle only one variable.

Here is a schema which represents our example according to the method of the variable sets, and according to the method of data objects / UML:

The old representation according to the method of the ensembles present simply the unique or common associations.
It is still useful to make project thinking and design.

While the more modern UML version gives more technical details on the naming of tables and the necessary association tables, thus more suitable for writing technical specifications.

We will therefore use either case by case in the documentation.

It's up to you to choose your own method of representation of course, this example is just here to help you read our schematics best in the documentation.