Component and services enable reuse and encapsulation of responsibilities and implementation details.
They come into play when a monolithic application and a monolithic code-base is not enough anymore.

When the code-base grows massively and so the number of people that work at the code-base, another principle that comes in to play is the Conway’s Law:

organizations which design systems . . .
are constrained to produce designs
which are copies of the communication structures
of these organizations.

The Conway’s Law puts in relation the components and services and the structure of teams that work at different components and services.

There are 2 well known and very different examples of putting in practices the OO principles and the Conway’s Law in order to deal with big code-bases and large teams.
One is the trunk based development used by Google and the other are the 1-pizza teams used by Amazon where every component and service is assigned to one small team.

It's important not to get confused: in both cases we are talking about cross-functional teams that take care of the implementation of business features. We are not talking about components teams (i.e. front-end teams, business logic teams and data-base teams) or any other types of specialized silos-like teams.