Greenfield Microservices von Tag 1. Ohne den Distributed Monolith.
Ihr startet ein neues System und wisst: Microservices, nicht Monolith. Die Frage ist nicht ob, sondern wie ihr den ersten Schnitt setzt, ohne in sechs Monaten beim Distributed-Monolith zu landen.
Greenfield-Microservices scheitern früh oder spät.
Nicht am Tooling. An den Bounded Contexts die niemand sauber geschnitten hat, bevor das erste Deployment lief.
Zu viele Services, zu früh
Acht Services für vier Devs. Jeder Endpunkt-Call ist jetzt ein Netzwerk-Call. Lokale Tests werden zur Orchestrierungs-Übung. Was als saubere Trennung gedacht war, wird zur Latenz-Maschine die ihr nicht mehr zurückbauen könnt.
Services teilen heimlich eine Domain
Order, Cart und Checkout sind drei Services. Im Code greifen sie auf dieselben Felder zu, mit minimal abweichender Semantik. Jede Änderung touched alle drei. Aus drei Microservices wird ein Distributed Monolith mit mehr Operations-Aufwand.
Jeder Service ist anders gebaut
Service A nutzt Repository Pattern, Service B Active Record, Service C ein eigenes Konstrukt. Onboarding bedeutet drei Codebasen lernen. Pattern-Drift ab Sprint 2. Konsistenz nur dort wo dasselbe Pair zweimal hintereinander gearbeitet hat.
Bounded Contexts zuerst. Services folgen.
Domain-Schnitt vor Deployment-Topologie. Jardis generiert jeden Bounded Context als eigenständiges PHP-Package mit identischer Architektur, sodass ihr später ohne Rewrite ausrollt was wirklich ein eigener Service sein muss.
Erst die Grenzen, dann die Services
Bevor du Container-Topologien designst, definierst du Aggregates und Bounded Contexts. Der Builder generiert pro Context die vollständige hexagonale Architektur. Welche Contexts am Tag 1 separat deployen und welche zusammen laufen ist eine reversible Entscheidung, kein Architektur-Lock-in.
OpenAPI und gRPC pro Service generiert
Jeder Bounded Context hat seinen Contract bevor die erste Zeile Code geschrieben wird. Synchron via REST oder gRPC, asynchron via Domain Events mit Queue Publishing. Wie Services miteinander reden ist im generierten Artefakt definiert, nicht im Onboarding-Doc von letztem Quartal.
Service 1 sieht aus wie Service 8
3-Layer Entities, Commands und Queries, Domain Events, Repository Pipeline. In jedem Service identisch. Ein Dev der Service Order kennt findet sich in Service Inventory in Minuten zurecht. Pattern-Drift wird strukturell verhindert, nicht durch Code-Review.
Warum Teams Greenfield-Microservices mit Jardis starten.
Weil das harte Problem nicht das Tooling ist, sondern die Domain-Schnitte zu treffen ohne sie nach drei Monaten zu bereuen.
Ein Service heute, zwei morgen
Jeder Bounded Context ist ein eigenständiges Package. Ob er als eigener Service deployt oder mit Nachbarn zusammenläuft ist eine Deployment-Entscheidung, keine Code-Migration. Korrekturen kosten Stunden, nicht Wochen.
Domain-Isolation strukturell erzwungen
Service A kann nicht direkt in die Daten von Service B greifen. Die Paketgrenzen erlauben es nicht. Kommunikation läuft über die generierten Contracts. Das klassische Greenfield-Antipattern wird im Code unmöglich.
Neue Services ohne Setup-Steuer
Der zehnte Service kostet dasselbe wie der erste: Aggregate definieren, Builder starten, Business-Logik schreiben. Kein Repo-Template das von der Realität abgehängt ist, keine Vorlage die jedes Team anders interpretiert.
Bereit, Microservices richtig zu starten?
Auf die WaitlistHäufige Fragen
Antworten zu Greenfield-Microservices mit Jardis.
So wenigen wie möglich, so vielen wie für eure Domain nötig. Das ist eine Domain-Frage, keine Technikfrage. Jardis trennt die beiden: ihr definiert Bounded Contexts unabhängig vom Deployment. Drei Contexts können am Tag 1 in einem Prozess laufen und später separat deployen, ohne Code-Rewrite.