Components are also known as building blocks. But what exactly is a component? A component is a software unit that can be independently replaced and upgraded. It has the following characteristics:
- It performs a specific function or provides certain services.
- It cannot operate independently and must function as part of a system.
- It is a physical concept, not a logical one.
- It can be maintained, upgraded, or replaced independently without affecting the entire system.
A component is a physically independent entity that can be maintained, upgraded, or replaced on its own. The purpose of creating a component diagram is to perform component-based design for the system, thinking about the physical division of the system, identifying which existing components can be reused, and determining which parts can be turned into components for reuse in future projects.
Question 1: When designing software, we often mention the term “module.” Is a module the same as a component?
Not necessarily. Everyone has different standards for what constitutes a “module.” Sometimes modules are divided based on business logic, and other times they are divided from a technical perspective. Modules are simply a way to divide software into parts for ease of explanation. You can refer to the characteristics of a component listed above to determine whether a “module” qualifies as a component.
Question 2: Software often uses layered design. Is each layer a component?
In most cases, each layer in a layered design is just a logical division and is not physically represented as separate files. In such cases, the layers are not components. However, the actual design may vary, and you can refer to the characteristics of a component to make a judgment.
Question 3: How do we distinguish between a “service” and a “component”?
A “component” refers to a software unit that will be used by other applications beyond the author’s control, but these applications cannot modify the component. In other words, an application using a component cannot alter the component’s source code, but it can extend the component in a predefined way to change its behavior.
Services and components share some similarities: both are used by external applications. In my view, the biggest difference between them lies in the fact that components are libraries used locally, such as JAR files, assemblies, DLLs, or source code imports. Services, on the other hand, are components external to the process, accessed by applications through mechanisms such as synchronous or asynchronous inter-process communication or remote interface calls (e.g., web services, messaging systems, RPC, or sockets).
Services can also call other services since a service is, in itself, an application.
You could map each service to a runtime process, though this is only an approximation. A service could consist of multiple processes, such as the main service application process and a database process used exclusively by that service.
Services can be deployed independently. If an application system is composed of multiple libraries within a single process, any modification to one component requires redeployment of the entire application. However, if the system is divided into multiple services, only the modified service needs to be redeployed—unless changes were made to its exposed interface.
Another outcome of implementing components as services is the availability of more explicit component interfaces.
Compared to in-process calls, remote service calls are more expensive in terms of performance.
References:
- “Microservices” by Martin Fowler
- “Inversion of Control Containers and the Dependency Injection pattern” by Martin Fowler
- “Fireball: UML and the War for Requirements Analysis”