Elements of Access: Unitary vs. Modular Architectures
Designs might be comprised of individual, discrete building blocks (modules) that are combined into a pattern, or may be holistic (unitary) so that a small part cannot simply be interchanged with something similar without breaking the whole design.
Most things are combinations of the two. Software has moved very much to modular architecture, and as systems become large and complex, this is a logical way of reducing complexity. On the other hand, there are advantages of integration, an airframe integrating the fuselage with a wing might be more aerodynamic or less expensive to construct or more structurally sound than a fuselage with wings attached (I don't know any of these things, but they might).
Another brick in the road.
In surface transport we have lots of modules: vehicles and infrastructure are often separated (in elevators they are not), bridges and roads are distinct, each link is a separate module, but you can't build half a link and expect it function. Poured asphalt is more unitary than individual bricks.
Traffic engineers operate on a system designed by highway engineers and planners and consider, for instance, the traffic signal timings as a distinct element that can optimized with everything else (lane configurations, pavement, etc.) fixed. Traffic engineers recognize that traffic signal timings affect the quality of flow upstream and downstream, and so will often time signals as a system, to optimize flow not just at the signal but for a corridor or a city network. This is recognition of a unitary aspect of the road network.
However this unitary nature of the network logic breaks the unitary nature of a neighborhood, where we might want the signals configured for pedestrians, and we might want roads redesigned to serve local rather than regional needs.
Elements of Access: Transport Planning for Engineers, Transport Engineering for Planners. By David M. Levinson, Wes Marshall, Kay Axhausen.
A modular architecture, where the signal is timed independently, obviously can do no better than the systemwide performance metric (mobility) of the overall system, but at least enables the maximization of the quality of the neighborhood if the appropriate local settings are chosen for the traffic signal module (at the expense of system-wide optimality on a mobility dimension). Similarly a purely local design may reek havoc with systemwide flow and have implications elsewhere on the network. While a module can only optimize for one master (and potentially less optimally than a unitary design), it can alternatively satisfice across multiple masters. In contradistinction, a unitary architecture must sacrifice one master for the sake of another. Modularization provides flexibility at the cost of at least one dimension of optimality. A unitary design lacks flexibility and adaptability. A new wing design will not help a unitary airframe.
We might further think about how systems change, either piece by piece or by replacement of the whole. Is a ship where every plank has been replaced one-by-one over the course of time still the same ship? We usually conclude it is. Is a ship which is burned down and replaced with a replica the same. We conclude it isn't. We will rename it, or at least give it a number or letter to distinguish it (Enterprise D). Continuity is important, and is enhanced by modularity.
The job of the designer is to understand these tradeoffs and select appropriate architectural strategies (unitary vs. modularity for particular design choices), and then design the modules as appropriate. While there is no one true path (this is not religious), there are consequences and values at play.