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.
These are the 6 forgot OO design principles about packaging cohesion & coupling that suggest criteria to group classes and responsibilities in components and services :
REP The Release Reuse Equivalency Principle The granule of reuse is the granule of release.
CCP The Common Closure Principle Classes that change together are packaged together.
CRP The Common Reuse Principle Classes that are used together are packaged together.
&
ADP The Acyclic Dependencies Principle The dependency graph of packages must have no cycles.
SDP The Stable Dependencies Principle Depend in the direction of stability.
SAP The Stable Abstractions Principle Abstractness increases with stability.
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.