Software developers sometimes use words without realizing what they mean. Want some examples? What is a module? Or a component? We're sure to quickly agree on method and class. But some terms require a definition. We have therefore created a Module hierarchyin which the "containers for logic" are housed.
Let's start with a list of the terms that will be discussed below:
- Method (method)
- Class
- Library (library)
- Package (packet)
- Component
- Microservice (microservice)
The illustration shows the hierarchy of the Modules. Module is the umbrella term here, i.e. a Component is a module, just like a Packageetc. The illustration shows how we can combine modules into ever larger units from bottom to top. Methods are summarized as Classesthese are summarized as Libraries etc.
Methods and classes (files)
At the lowest level we have Methods and Classes as modules that contain logic in textual form. In all languages, methods in Files are filed. This also applies to those in which no Classes are available or are not absolutely necessary. In this respect, the term Class be understood as synonymous with File.
We could use the term Method can now be precisely defined. However, I suspect that our ideas about what constitutes a Method are very similar. In this respect, I will spare us a formal definition.
Libraries
Classes resp. Files can lead to Libraries are summarized. In .NET these are DLLs, in Java JAR files, in C++ .lib or .a files etc. The most important difference to the levels below: from this level onwards, the logic is only available in binary form, no longer as text. Even in interpreted languages such as Python or JavaScript, where the source code may technically exist, we do not see it as users. How a Library is technically stored in the file system is transparent to the user. In this respect, one can also speak of a quasi-binary representation for the interpreted languages. Libraries are used for deployment.
Package
Let us add to a Library metadata and versioning are added, the result is a Package. What is meant here is not version control like git, but an infrastructure that allows us to include packages of different versions. The other packages on which each package depends are also stored. Version numbers are also stored so that the required dependencies can also be provided when a package is added to a project. Examples of package technologies are NuGet, Maven, npm, pip and others.
If you tried to reuse logic based on libraries, it would be very difficult to recognize whether a new version is available. Furthermore, when libraries are used directly, the dependencies themselves must be provided. Packages are therefore primarily used for reuse.
Component
For implementation based on division of labor Contracts required. Before the division of labor can be implemented, the contracts must clarify how the individual components will later be combined, i.e. integrated. The contracts define the interaction of the parts and serve to delimit them. Technically speaking, interfaces and data types are used for the contracts. These contracts must already exist before they can be implemented. Consequently, they must be stored separately from the implementation. There is therefore a Component from at least two packages: one contains the contracts, the other(s) the implementation.
In the case of contracts, we can first distinguish between implicit and explicit Contracts. Every method and class has an implicit contract. For methods, this is the signature. For example, a method can be called via its implicit contract if the name is used correctly and the conventions for the parameters are adhered to.
A contract becomes explicit when an interface is defined. The method or class must implement this explicit contract and can then be called via the contract. For methods, an explicit contract is, for example, a delegate Definition in .NET. If a method expects an object of type Actionthis method can be called via this explicit contract. At runtime, all methods that adhere to this explicit contract can be used.
For classes the Interface the explicit contract.
If the contract is separated from the implementation into a separate package, this is referred to as a separate contract. Components are therefore binary modules with a separate contract. Components are used for implementation based on division of labor.
Microservice
Microservices form the top level of the module hierarchy. They differ from components in that they have a platform-neutral contract have. This can be defined as an http/REST interface, for example. This means that it does not matter which platform is used to implement a microservice. A Java microservice can call a .NET microservice as long as it adheres to the platform-neutral contract.
Microservices are used for deployment.
Conclusion
A Term is a Word with Meaning. When software developers talk to each other and discuss different possible solutions, for example, it is essential that they Terms are used instead of empty words. Only if everyone in the team is clear about what the word Package is meant, a meaningful conversation can take place. The word Package then becomes a term by which everyone understands the same thing. If two developers have a different meaning of the word Component In the end, the mental models in the heads of these developers will differ and misunderstandings are inevitable.
Unfortunately, the terms listed here are not uniformly defined in computer science. Here is how we use these terms at the CCD Academy. So be prepared for other developers or authors to use some terms differently. Especially for Component and Module there is a high risk that a different meaning is intended. If in doubt: ask and clarify.
English 
German
1 thought on “Die Modulhierarchie”
Pingback: Software architecture: responsibilities and dependencies - CCD Akademie GmbH