• a) Komplexität von APIs geringer

• b) kein „unzuverlässiges Netzwerk“ erforderlich - common fallacys of networking

• c) kleinerer Technologiestack erforderlich

• d) Fehlersuche unter Umständen einfacher, bei MS umfangreiches Monitoring erforderlich

• e) Wissen kann einfacher als Paket eingekauft werden (fraglich, Vorteil möglicherweise nur gefühlt)

• f) Transaktionalität ist einfacher möglich

• g) Skalierbarkeit einzelner Komponenten nach Bedarf - auch finanzieller Aspekt

• h) viel Opensource Software (Orchestrierung, Betrieb) steht zur Verfügung

• i) Architektur tendiert nicht so stark zu Verklumpung - Monoltith: Riskio das die „wohlstrukturiertheit“ verloren geht

• j) Unabhängige crossfunktionale Teams können sich um einzelne Teilbereiche kümmern

• k) einzelne Komponenten/Teams können unabhängig voneinander Arbeiten/Deployen (bei Monolith schwieriger)

• l) organisatorische Gegebenheiten können besser abgebildet werden (entspricht eher der Domäne)

• m) Technologieunabhängigkeit erlaubt flexiblere Auswahl von erforderlicher Expertise

• n) Risiko das sich legacy Software und Technologie ansammelt, für die später keine Experten mehr zur Verfügung stehen ist geringer

• o) Möglichkeit eines kleineren unabhängigeren Datenmodells

zu a) APIs müssten für andere Subdomänen ohnehin zur Verfügung gestellt werden => spricht nicht gegen MS

zu b) für unsere Subdomäne ist viel interne Netzwerkkommunikation zwischen den einzelnen MS erforderlich, diese ist durch ein instabiles Netzwerk gefährdet => spricht eher für einen Monolithen

zu c) Nutzung von Technologiestack stellt Mehraufwand dar (Docker, Kafka, theoretisch Kubernetes).

=> spricht eher für einen Monolithen

zu d) Nutzung von ohnehin erforderlichem Technologiestack erlaubt automatisiertes Monitoring => kein Nachteil bei Einsatz MS

zu e) Vorteil nicht relevant

=> kein Vorteil Monolith in unserem Anwendungsfall

zu f) Strenge Transaktionalität in unserer Domäne nicht erforderlich

=> kein Vorteil Monolith

zu g) Die zu erwartende Last liegt nicht in einem Bereich der umfangreiche Skalierbarkeit erfordert

=> kein Vorteil MS

zu h) Da es sich um ein Opensource Projekt handeln soll ist es von Vorteil wenn es selbst auf Opensource aufbaut (Aufbau Monolith auf OSS sollte ebenfalls möglich sein)

=> Kein klarer Vorteil MS

zu i) Tendenziell problematisch. MS könnten hier helfen, es kommt aber auf die Disziplin des Teams an.

=> leichter Vorteil für MS

zu j) Unsere Subdomäne wurde nochmals unterteilt, jedoch wäre dies vermutlich nicht zwingend erforderlich (größe der Subdomäne).

=> leichter Vorteil für MS

zu k) wird von uns in unserer Subdomäne genutzt

=> klarer Vorteil MS

zu l) In unserer Domäne liegen nur wenig organisatorische Rahmenbedingungen vor die abgebildet werden könnten.

=> kein klarer Vorteil MS

zu m) wenn das Projekt weitergegeben wird ist die Auswahl der zur Verfügung stehenden Experten die es übernehmen könnten größer

=> klarer Vorteil MS

zu n) Relevanz für unsere Domäne nicht unmittelbar ersichtlich

=> kein klarer Vorteil MS

zu o) kleines Datenmodell für uns von Vorteil, weniger Aufwand zur Abstimmung

=> Vorteil für MS

Zusätzliche Annahmen:

Der Umfang unseres Bounded Context ist relativ gering und die einzelnen Funktionalitäten sind untereinander eng verbunden.

=> spricht eher für einen Monolithen

In der Gesamtschau überwiegen die durch die Anwendung von MS gewonnen Vorteile.

Allerdings wäre es, aufgrund des Umfangs unserer Subdomäne, ebenfalls angemessen gewesen diese als einzelnen MS zu implementieren, anstatt sie nochmals in mehrere MS aufzuteilen.

Wir würden uns also weiterhin für MS entscheiden, unsere Subdomäne jedoch durch einen einzigen MS abdecken.

Unserer Meinung nach handelt es sich um eine taktische Entscheidung, insofern die Entscheidung nur unsere Domäne betrifft und die resultierende Software als MS begriffen werden kann.

Sollen aber die Vorteile von Monolithen wie weniger Netzwerkkommunikation, Transaktionalität, weniger komplexität in den APIs oder ein kleinerer erforderlicher Technologiestack genutzt werden müsste die Entscheidung strategisch fallen.