Sembra che ti stia concentrando su un punto specifico nell'articolo di Mark Richard senza considerare il contesto che il resto del documento fornisce.
Leggi i seguenti tre paragrafi (citati nel documento). Ho evidenziato alcuni punti chiave in grassetto:
SOA is well-suited for large, complex, enterprise-wide systems that
require integration with many heterogeneous applications and services.
It is also well-suited for applications that have many shared
components, particularly components that are shared across the
enterprise. As such, SOA tends to be a good fit for large insurance
companies due to the heterogeneous systems environment and the
sharing of common services—customer, claim, policy, etc.—across
multiple applications and systems.
However, workflow-based applications that have a well-defined processing
flow and not many shared components (such as securities
trading) are difficult to implement using the SOA architecture pattern.
Small web-based applications are also not a good fit for SOA
because they don’t need an extensive service taxonomy, abstraction
layers, and messaging middleware components.
The microservices pattern is better suited for smaller, well-partitioned
web-based systems rather than large-scale enterprise-wide
systems. The lack of a mediator (messaging middleware) is one
of the factors that makes it ill-suited for large-scale complex business
application environments. Other examples of applications that
are well-suited for the microservices architecture pattern are ones
that have few shared components and ones that can be broken down
into very small discrete operations.
Ciò che l'autore sta dicendo, in poche parole, è che la SOA è più adatta a sistemi ampi e diversi con componenti eterogenei; cioè, sistemi che devono comunicare tra loro, ma ognuno con interfacce e protocolli dati diversi.
OK, ora leggi i seguenti tre paragrafi:
Contract decoupling is the holy grail of abstraction. Imagine being
able to communicate with a service using data in a message
format that differs from what the service is expecting—that is the
very essence of contract decoupling.
Contract decoupling allows services and service consumers to evolve independently from each other, while still maintaining a contract
between them. It also helps give your service consumers the ability
to drive contract changes, thereby
creating a more collaborative relationship between the service and
the service consumer.
There are two primary forms of contract decoupling: message transformation
and message enhancement. Message transformation is
concerned only about the format of the message, not the actual
request data. For example, a service might require XML as its input
format, but a service consumer decides to send JSON payload
instead.
L'asserzione originale dell'autore dovrebbe ora essere evidente:
Microservices architecture does not support contract decoupling, whereas contract decoupling is one of the primary capabilities offered within a SOA.
Naturalmente, se consideri che la dichiarazione sia evidente o meno, dipende interamente da te. Non mi è chiaro perché un'architettura di microservizi precluderebbe l'uso di meccanismi di disaccoppiamento del contratto, anche se è probabilmente vero che SOA supporta tale "middleware" in modo più robusto, o fornisce tale middleware fuori dalla scatola in modo che non sia necessario scriverlo te stesso.