What is the difference between a crow and a desk? Or the difference between "their" modules and "our" components.
Actually, this text serves as a development of the topic about the comparative advantages of modular and monolithic systems .
Teaching practice once again gave birth to an interesting question. “So why should you blame the drawbacks of modular systems for nothing, and sell components yourself. Actually, what's the difference? "
Fiercely, furiously identifying with Descartes, we will first agree on the meaning of words.
What is a module.
NB: hereinafter, it is solely in the context of the conceptual apparatus of ERP-systems.
')
So, the “module” is a system functionality that has its own data processing logic and implements a block of business processes within itself .
The module can be implemented as a separate application, or be part of another.
The module is weakly dependent on the rest of the system (actually, the aggregate of the remaining modules).
The module can either have a separate storage for data (the need for synchronization with the main data storage follows), and create its own structures in the main storage.
An abstract example is the warehouse module.
It assumes the presence of some kind of logic for storing data. In the spirit of which shelf a particular product is on, etc.
Therefore, the storage module must have the following directories (shelves etc).
If the warehouse module is implemented by a separate application (historically, in many cases - by acquiring a company that produced warehouse software), then it will store the data in its own storage, and in some way or another replicate to the main storage.
However, it can immediately work with the main repository, it is actually not so important.
Components.
The component for the Ultima Businessware platform is a separate application integrated with the platform by a particular protocol (REST API, SOAP or its own, binary protocol).
The component does not store the raw data in its system, but always transfers it to the central system . The component acts as a “data mart” or client application in relation to the application server.
Primary data - business-relevant data generated by users of the system (including clients through external interfaces). For example, the contents of the delivery note, shipping address, billing date, etc.
The component, unlike the module, does not have its own business logic , sharing code that implements business logic (encapsulated, as in any system of a full-fledged 3-tier architecture, inside the application server) with all other parts of the system.
A component may have its own data storage, but it is used exclusively for caching information.
For example, the engine for creating online stores Ultima eStore has its own mini-database for intermediate storage of the price cache, stock balance and description of goods. But only.
When registering users or creating an order in the mini-database of the eStore, no data is left, they are transmitted online through the application server to the main repository. Therefore, we note in parentheses, the procedure for creating a client when registering on the site or the operator when calling the call center / seller in the store is absolutely identical, the only difference is in the interface used.
A slightly different option of using local storage is observed in the case of the component for warehouse automation Ultima MobileWMS .
Operating conditions require maximum processing speed of the scanned barcode - therefore, wherever possible, a database of barcode residues is loaded into the local storage.
Local storage data is used exclusively to answer the question: does the scanned barcode belong to the desired product, yes / no. Due to caching in the local storage, you can quickly report errors while typing. The "correct" barcode is sent to the application server, further processing is carried out according to the general business logic of the system.
But the component for the Ultima Door-to-Door salesman or the mobile viewer / signer of the Ultima MobileView does not even have any local storage in any form.
Because there is no need: the operational requirements quite allow you to work directly from the central database.
Thus, the components of Ultima Businessware, on the one hand,
and on the other
As a result, development and testing is significantly simplified and accelerated. Speaking with money, the support of the system as a whole is becoming cheaper, while not at the expense of quality.
Formulating from the point of view of the consumer, the component approach allows to get all the advantages of the modules without their minuses - that is, completely preserving the solidity of the architecture as a whole.
Teaching practice once again gave birth to an interesting question. “So why should you blame the drawbacks of modular systems for nothing, and sell components yourself. Actually, what's the difference? "
Fiercely, furiously identifying with Descartes, we will first agree on the meaning of words.
What is a module.
NB: hereinafter, it is solely in the context of the conceptual apparatus of ERP-systems.
')
So, the “module” is a system functionality that has its own data processing logic and implements a block of business processes within itself .
The module can be implemented as a separate application, or be part of another.
The module is weakly dependent on the rest of the system (actually, the aggregate of the remaining modules).
The module can either have a separate storage for data (the need for synchronization with the main data storage follows), and create its own structures in the main storage.
An abstract example is the warehouse module.
It assumes the presence of some kind of logic for storing data. In the spirit of which shelf a particular product is on, etc.
Therefore, the storage module must have the following directories (shelves etc).
If the warehouse module is implemented by a separate application (historically, in many cases - by acquiring a company that produced warehouse software), then it will store the data in its own storage, and in some way or another replicate to the main storage.
However, it can immediately work with the main repository, it is actually not so important.
Components.
The component for the Ultima Businessware platform is a separate application integrated with the platform by a particular protocol (REST API, SOAP or its own, binary protocol).
The component does not store the raw data in its system, but always transfers it to the central system . The component acts as a “data mart” or client application in relation to the application server.
Primary data - business-relevant data generated by users of the system (including clients through external interfaces). For example, the contents of the delivery note, shipping address, billing date, etc.
The component, unlike the module, does not have its own business logic , sharing code that implements business logic (encapsulated, as in any system of a full-fledged 3-tier architecture, inside the application server) with all other parts of the system.
A component may have its own data storage, but it is used exclusively for caching information.
For example, the engine for creating online stores Ultima eStore has its own mini-database for intermediate storage of the price cache, stock balance and description of goods. But only.
When registering users or creating an order in the mini-database of the eStore, no data is left, they are transmitted online through the application server to the main repository. Therefore, we note in parentheses, the procedure for creating a client when registering on the site or the operator when calling the call center / seller in the store is absolutely identical, the only difference is in the interface used.
A slightly different option of using local storage is observed in the case of the component for warehouse automation Ultima MobileWMS .
Operating conditions require maximum processing speed of the scanned barcode - therefore, wherever possible, a database of barcode residues is loaded into the local storage.
Local storage data is used exclusively to answer the question: does the scanned barcode belong to the desired product, yes / no. Due to caching in the local storage, you can quickly report errors while typing. The "correct" barcode is sent to the application server, further processing is carried out according to the general business logic of the system.
But the component for the Ultima Door-to-Door salesman or the mobile viewer / signer of the Ultima MobileView does not even have any local storage in any form.
Because there is no need: the operational requirements quite allow you to work directly from the central database.
Thus, the components of Ultima Businessware, on the one hand,
- allow to bring out a specific specific professional functionality (by and large, a special interface)
and on the other
- do not lead to the sad consequences characteristic of classical modular systems. Described, in turn, in the articles, links to which have already been given above.
As a result, development and testing is significantly simplified and accelerated. Speaking with money, the support of the system as a whole is becoming cheaper, while not at the expense of quality.
Formulating from the point of view of the consumer, the component approach allows to get all the advantages of the modules without their minuses - that is, completely preserving the solidity of the architecture as a whole.
Source: https://habr.com/ru/post/251903/
All Articles