Modular design

Modular design divides a system into components with defined interfaces, allowing components to be developed, replaced, or combined with limited changes to other parts.

Interface (computing): A defined boundary through which software components or systems exchange information or services. Interfaces specify how modules interact while concealing their internal implementation.
Decomposition (computer science): The division of a complex computational problem or system into smaller parts. Modular design uses decomposition to create components with bounded responsibilities.
Microservices: An architectural style that structures an application as independently deployable services. Microservices apply modular boundaries to separately deployed software services.
Monolithic architecture: A software architecture in which an application is built and deployed as one integrated unit. A monolith concentrates implementation and deployment instead of dividing them among modules.
Software product line: A family of related software products built from shared core assets and controlled variations. Reusable modules can support product families with systematic feature variation.
Information hiding: A software design principle that conceals a component’s internal details behind a stable interface. It lets a module change internally without forcing changes in its users.
Abstraction (computer science): A way of representing a system by emphasizing relevant features and hiding detail. Interfaces expose an abstraction of each module rather than its implementation.
Plugin architecture: A software architecture that extends a core application through replaceable or addable plugins. Plugins are modules added through interfaces without rewriting the application core.
Integral design: A design approach in which components perform multiple functions and depend strongly on one another. Integral designs rely on interdependent components rather than clearly separated modules.
Technical debt: The future cost of maintaining a system after expedient design or implementation choices. Poorly chosen boundaries can make cross-module changes costly and accumulate maintenance burden.

Linked from 10 pages