Ich freue mich schon jetzt auf Argumente und Begriffsdefinitionen.
Zuerst sollte man mal zwischen Microservice und Microservice-Architektur unterscheiden. In Anlehnung an den von Balzert verwendeten Architekturbegriff bezeichnet Microservice-Architektur die Softwarearchitektur eines verteilten Systems dessen Architekturbausteine Microservices sind.
Beim Microservice gibt es dagegen so viele Betrachtungsweisen, dass es nicht möglich ist, eine explizite, geschlossene Definition anzugeben. Der kleinste gemeinsame Nenner wurde m. E. von Dragoni et al. beschrieben, wonach es sich bei Microservices um unabhängige, kohäsive Prozesse handelt, die über Nachrichten interagieren. Dabei würde ich allerdings noch das Netzwerk als zusätzliches Charakteristikum anführen, um sich von z. B. Unix-Tools abzugrenzen, außerdem darf man den Prozessbegriff nicht zu eng auslegen. Vielmehr muss hierunter fallweise auch die Anwendung verstanden werden, während der Betriebssystemprozess dann eine konkrete Instanz des Microservices wäre.
Das Interessante an diesem Kriterium ist, dass es auf der einen Seite sehr allgemein gehalten ist, andererseits eine Beschreibung liefert, die präzise genug ist, um ableiten zu können, worauf es im Wesentlichen ankommt. Insbesondere wird die Größe implizit über die Kohäsion nach oben und unten bereits eingeschränkt.
Auswirkungen sind die hier bereits genannten:
Bei Übertragung auf DDD liefert der bounded context, wie von
@Barista bereits geschrieben, die Grenze nach oben. Das Aggregate als transaktionale Einheit würde dagegen das absolute Minimum darstellen, was von einem Microservice abgedeckt werden kann.
Die Unabhängigkeitsforderung liefert mit Blick auf die DB, dass jeder Microservice seine eigene Daten hält. Außerdem muss er alle Abhängigkeiten mitbringen, um ausgeführt werden zu können. Daraus ergeben sich im Zusammenhang mit Conway's Law dann auch die von
@Ebi bechriebenen Konsequenzen.
So viele Vorteile Microservices auch haben mögen, so sehr muss man sich der Komplexität bewusst werden. Eine verteilte Anwendung ist nun einmal eine ganz andere Hausnummer als ein Monolith. Man muss zusätzlichen Aufwand in die Kommunikation stecken und das CAP-Theorem schlägt gnadenlos zu. ACID vs. BASE. Hurra.
Daher: Microservices so viel als nötig, so wenig wie möglich. Ohne fundierte Gründe keine Microservice-Architektur, wobei es sehr viele Gründe geben kann, die auch über die Strukturen im Betrieb etc. hinausreichen.