While Architectural Design shows us the "neighborhood" (the big blocks), Component-Level Design takes us inside the "house" to look at the specific wiring and plumbing of a single module.
It is the lowest level of design, where we define the internal algorithms, data structures, and communication interfaces of a specific software component before we start writing code.
📂 The "Three Views" of a Component
Depending on who is looking at the design, a component can be defined in different ways:
The Object-Oriented View: A component is seen as a set of collaborating classes. Each class is fully described with its attributes and operations.
The Conventional View: A component is seen as a functional element or module that performs a specific logic (common in non-OOP languages like C).
The Process-Related View: The component is viewed as a "system building block" that is plucked from a library of existing components (like a UI widget or a cloud authentication service).
📏 Basic Design Principles (The "Checklist")
When designing an individual component, engineers follow these four specific guidelines to ensure quality:
The Open-Closed Principle (OCP): You should be able to add new functionality to the component without changing its existing code.
The Liskov Substitution Principle (LSP): Any subclass should be able to stand in for its parent class without the system breaking.
The Dependency Inversion Principle (DIP): The component should depend on "abstractions" (interfaces) rather than "concretions" (hard-coded details).
The Interface Segregation Principle (ISP): Don't force a component to implement functions it doesn't need. Keep interfaces thin and specific.
🛠️ Component-Level Design Process
How do you actually design a component? You follow these steps:
Identify Classes/Modules: Look at your architectural diagram and pick one block to zoom in on.
Define Interfaces: Specify exactly what data goes in and what comes out.
Detail Data Structures: Decide how data will be stored inside that component (e.g., using a Linked List vs. an Array).
Describe Algorithms: Use Pseudocode or Activity Diagrams to map out the logic (e.g., "If user is logged in, then fetch data, else show error").
Review: Ensure the component has High Cohesion (does one job) and Low Coupling (doesn't lean too hard on other components).
📊 Component vs. Class
Feature | Class | Component |
|---|---|---|
Granularity | Small (Single entity). | Large (Collection of classes). |
Focus | Logic and Data attributes. | Deployment and Execution. |
Interaction | Method calls. | Interface "Plugs" (APIs/Ports). |
Analogy | A single brick. | A pre-fabricated wall. |
💡 The Takeaway
Component-Level Design is where the "magic" happens. If you skip this and go straight to coding, you end up with "Spaghetti Code." If you do this well, your code will be so organized that it almost writes itself.