module and component both name parts of software, but the dividing line depends on context. architecture describes the larger arrangement; abstraction reveals a useful boundary while hiding irrelevant detail. Read API and middleware the same way: identify the responsibility and interaction boundary, not just a dictionary synonym.
Core words
The diagram compares levels of design: an overall structure, functional units, responsible parts, and the exposed boundaries between them.
| English term | Meaning and use |
|---|---|
system architecture | The arrangement of a system's major parts, their responsibilities, and how they interact. It can describe structure and operating principles. |
middleware | Software between other layers or components that mediates requests, data, or shared services; the exact placement depends on the platform. |
Entity | A distinguishable thing in a domain model or data model, such as a person, order, or vehicle. In a particular framework, “entity” may have a narrower persistence meaning. |
dependency | A relationship in which one part needs another part, service, package, or condition to work. |
semantics | The meaning or behavior of a valid expression, in contrast with its syntax or grammatical form. |
UML(Unified Modeling Language) | A standardized visual modeling notation with diagram types used to communicate aspects of software structure and behavior. |
Words to distinguish together
| English term | Meaning and use |
|---|---|
module | A cohesive unit of code or functionality with a defined boundary. A module may be a package or compilation unit depending on the language and system. |
Modularity | The design property of dividing a system into such units so changes, tests, and reuse can be managed more locally. It does not guarantee performance by itself. |
abstraction | A model or interface that keeps relevant properties visible while hiding details unnecessary for the current task. |
component | A part with a recognizable responsibility and interface. It may be a UI unit, deployable service, or larger subsystem depending on context. |
coupling | The degree and kind of dependence between parts. Lower unnecessary coupling often makes change easier, but some dependence is essential. |
cohesion | How closely a unit's responsibilities belong together. Higher functional cohesion usually makes a unit easier to understand. |
Words encountered in code and designs
| English term | Meaning and use |
|---|---|
reuse | Using an existing part in another context, sometimes after adapting it rather than copying it unchanged. |
design pattern | A named, reusable solution structure for a recurring design problem, with context and tradeoffs. |
SOA | Service-Oriented Architecture: an approach to organizing capabilities as interoperable services with defined contracts. |
Singleton | A pattern providing one instance within a defined scope and a way to access it; it does not automatically mean one instance across processes or machines. |
A passage from technical documentation
A module and a component can overlap, but their names do not automatically make their deployment unit or responsibility boundary the same.
To read a design description, identify whether a word refers to the whole arrangement, a unit of code, a unit of responsibility, or the contract between units. Then ask what scope the author has chosen. A “component” in a UI library and a “component” in a distributed architecture may be different sizes.
Key takeaways
Look at the whole structure, the chosen units, and their dependencies together. system architecture names the arrangement; abstraction sets a useful view of a boundary; Singleton constrains instances only within its specified scope.
