THE PRODUCT-MODULE WORKING MODEL

MODULE

is derived from the run.sh project in GitHub https://github.com/csitea/run.sh
created by MODULE=<> ./run -a do_zip_me_as_module
- the developer can modify the files to be included during the packaging / creation
- the developer can modify the file glob patterns to use for exclusion of files into the package
is deployable locally via oneliner by: unzip -o <<path-to-module-zip>> -d .
1 or more modules comprise a product
each module is a product and each product is a module
follows the naming conventions for:
- PRODUCT – the product name, which is the base name of the :
- `PRODUCT_PATH` – the root dir of the software project of the product
  - BASE_PATH ( typically , but no nesessarily /opt/ )
  - ORG_PATH – the name or the abbreviation of the organisation for which the product is created for
  - <<PRODUCT_PATH>>/src/<<run-time>>/<<module-name>> , where the run-time can by
    - python
    - nodejs
    - docker
  - <<PRODUCT_PATH>>/dat stores all the data of the module ( if any )
  - <<PRODUCT_PATH>>/cnf stores all the configuration of the module ( if any )
  - <<PRODUCT_PATH>>/src stores all the source code of the module
  - <<PRODUCT_PATH>>/bin stores all the binaries of the module ( if any )
often used to isolate one single run-time code to a developer to hinder complexity
modules could use the file system to share common data within a PRODUCT
each module usually has it’s own Dockerfile for full e2e isolation OS wise

can have 1..* MODULES
but it can contain additional code combining those
is a module
can become a module to be used in a larger product
the <<PRODUCT_PATH>>/dat is used
multiple products based under the same <<BASE_PATH>>/<<ORG_PATH>> can share common data
a product might have docker-compose pointing to different modules