Understanding Software Components

Key Insight

Software components represent the physical packaging of modules, acting as language-specific mechanisms to group related artifacts. Common examples of this physical packaging include Java's 'jar' files, .NET's 'dll' files, and Ruby's 'gem' files. These components offer a higher level of modularity compared to basic language constructs like classes or functions, establishing themselves as fundamental modular building blocks in architecture. A crucial initial decision for architects is determining the top-level partitioning of these components within the overall architecture.

Components can be broadly categorized based on their operational characteristics. 'Libraries' are a simpler form, often wrapping code at a higher level of modularity than classes, and typically run within the same memory address space as the calling code. They communicate via standard language function calls and are usually compile-time dependencies, with dynamic link libraries (DLLs) being notable exceptions. Beyond libraries, components also appear as 'subsystems' or 'layers' within an architecture, frequently serving as deployable units for various event processors.

A distinct and more independent type of component is a 'service', which operates in its own dedicated address space. Services communicate using low-level networking protocols like TCP/IP, or higher-level formats such as REST or message queues. These services function as stand-alone, deployable units, forming the core of architectures like microservices. Although not strictly mandatory, employing components proves highly beneficial for architects who require a level of modularity beyond the lowest offerings of a programming language, guiding essential architectural design choices.