Is an excellent book by Sam Newman.
As usual I'm going to quote from a few pages...
Because microservices are primarily modeled around business domains,
they avoid the problems of traditional tiered architectures.
Microservices should cleanly align to bounded contexts.
Another reason to prefer the nested approach could be to chunk up your
architecture to simplify
testing.
With an event-based collaboration,
we invert things. Instead of a client
initiating requests asking for things to be done, it instead says
this thing happened and expects other parties to know what to do.
We never tell anyone else what to do.
We always
want to maintain the ability to release microservices independenty of each other.
A red build means the last change possibly did not intergrate. You need to stop all
further check-ins that aren't involved in fixing the build to get it passing again.
The approach I prefer is to have a single CI build per microservice, to allow us to
quickly make and validate a change prior to deployment into production.
No changes are ever
made to a running server.
Rather than using a package manager like debs or RPMs, all software is
installed as independent Docker apps, each running in its own container.
Flaky tests are the enemy. When they fail, they don't tell us much...
A test suite with flaky tests can become a victim of what Diane Vaughan calls the
normalization of deviance - the idea that over time we can become so
accustomed to things being wrong that we start to accept them as being normal
and not a problem.
All too often, the approach of accepting multiple services being deployed together
drifts
into a situation where services become coupled.
Most organizations that I see spending time creating functional
test suites often expend little or no effort at all on better monitoring or
recovering from failure.
