Modulaire monoliet vs microservices in PHP: hoe beslis je?

De keuze tussen een modulaire monoliet vs microservices in PHP wordt niet bepaald door het aantal modules, de ouderdom van de code of de populariteit van een architectuur. Een bedrijfsapplicatie kan gezond groeien binnen één enkele uitrol als zij duidelijke grenzen behoudt. Omgekeerd kan haar voortijdig opsplitsen eenvoudige interne aanroepen veranderen in een netwerk van contracten, wachtrijen, herhaalpogingen en coördinatieproblemen.

De nuttige vraag is niet: «moeten we microservices gebruiken?», maar: «welke bedrijfsfunctie moet onafhankelijk kunnen evolueren, falen, worden uitgerold of schalen, en kunnen we de kosten dragen om die op die manier te beheren?». Het antwoord moet uitgaan van het domein en de feitelijke bedrijfsvoering, niet van een streefdiagram.

Functionele groei vereist geen afzonderlijke diensten

Het toevoegen van integraties, asynchrone processen of productgebieden betekent niet dat elk daarvan een eigen dienst moet hebben. Een monoliet kan goed afgebakende modules, achtergrondtaken, wachtrijen en adapters voor externe systemen bevatten zonder operationele samenhang te verliezen.

De eerste ingreep is doorgaans het verminderen van de interne koppeling. Als een facturatiemodule rechtstreeks orderklassen importeert, hun tabellen wijzigt of interne voorraadregels kent, wordt het probleem niet automatisch opgelost door code naar een andere repository te verplaatsen. Het verandert alleen in netwerk- en datakoppeling.

Een modulaire monoliet streeft ernaar dat elke functie een expliciete interne interface, gerichte afhankelijkheden en eigen regels heeft. In PHP kan dit worden vormgegeven met naamruimten per domein, applicatiecontracten, dunne controllers, gedefinieerde use cases en adapters voor persistentie of externe API's. Alles samen uitrollen blijft verenigbaar met deze grenzen.

Wat te analyseren voordat je de architectuur wijzigt

Identificeer vóór je technologie bespreekt de bedrijfsfuncties: bijvoorbeeld orderbeheer, catalogus, identiteit, facturatie, documentverwerking of meldingen. Een functie is niet noodzakelijk gelijk aan een entiteit of een scherm; zij bundelt regels en beslissingen die om vergelijkbare redenen zouden moeten veranderen.

• Eigenaar: bepaal wie de regels onderhoudt, wijzigingen prioriteert en verantwoordelijk is bij incidenten.
• Gegevens: identificeer welke informatie elke functie creëert en beheert, wie deze mag wijzigen en welke gegevens uit andere domeinen zij moet raadplegen.
• Kritieke stromen: teken het verloop van een relevante handeling, inclusief validaties, externe afhankelijkheden en asynchrone stappen.
• Verandertempo: onderscheid frequente wijzigingen van incidentele veranderingen. Frequentie op zichzelf is niet voldoende; van belang is of zij teams of releases tot coördinatie dwingt.
• Belastingsprofiel: scheid interactief verkeer van taken die intensief zijn voor CPU, geheugen, opslag of aanroepen van derden.
• Impact van falen: leg vast wat er gebeurt als een functie minuten of uren degradeert en of de kern van het bedrijf kan blijven functioneren.

Deze inventaris onthult afhankelijkheden die vaak verborgen blijven: gedeelde transacties, rechtstreekse query's op tabellen van anderen, gedupliceerde regels in controllers en geplande taken die meerdere domeinen bijwerken. Een capaciteit afzonderen zonder die afhankelijkheden vooraf op te lossen, levert formeel gescheiden maar functioneel verweven diensten op.

Zes signalen om een modulaire monoliet te behouden

Deze signalen pleiten ervoor het interne ontwerp te versterken in plaats van verantwoordelijkheden te verdelen:

1. Wijzigingen lopen doorgaans door meerdere modules heen. Als een bedrijfsfunctionaliteit gecoördineerde wijzigingen aan orders, prijzen en facturatie vereist, kan opsplitsing het aantal uitrollen en contracten vermenigvuldigen.
2. Directe consistentie is cruciaal. Wanneer een handeling één databasetransactie nodig heeft om kritieke invarianten te behouden, voegt een gedistribueerde grens complexe compensatiebeslissingen toe.
3. Het team is klein of deelt het eigenaarschap. Meerdere diensten vereisen operationele discipline, wachtdiensten, pijplijnen, versies en diagnose voor elke eenheid.
4. De belasting schaalt op vergelijkbare wijze. Als componenten in hetzelfde tempo groeien en er geen isoleerbare bottleneck bestaat, biedt scheiding geen duidelijk voordeel.
5. De domeingrenzen zijn nog instabiel. Een functie afzonderen terwijl haar regels, vocabulaire en verantwoordelijkheden voortdurend veranderen, legt een voortijdige grens vast.
6. Waarneembaarheid en automatisering zijn beperkt. Zonder gestructureerde logboeken, meetwaarden, sporen, waarschuwingen en herhaalbare uitrollen maakt elke netwerksprong het kostbaarder om een incident te onderzoeken.

De monoliet behouden betekent niet dat je globale code accepteert. Het doel is dat de module met logische autonomie kan evolueren, ook al deelt zij proces, repository en release met andere modules.

Zes signalen die een onafhankelijke dienst rechtvaardigen

Afzondering is beter verdedigbaar wanneer meerdere van deze voorwaarden samenkomen, niet wanneer er slechts één aanwezig is:

1. Er bestaat een afgebakende en begrijpelijke verantwoordelijkheid. De dienst heeft een concrete missie, samenhangende regels en een eigen domeintaal.
2. Ze kan eigenaar zijn van haar data. Ze beheert haar opslag en stelt overeengekomen handelingen, gebeurtenissen of query's beschikbaar, in plaats van directe toegang tot haar tabellen toe te staan.
3. Ze heeft echt onafhankelijke uitrollen nodig. Haar wijzigingscyclus moet vooruit kunnen zonder elke release met de kern te coördineren.
4. Haar belasting is afwijkend. Een proces voor conversie, zoeken, bestandscreatie of intensieve berekening kan andere schaalbaarheid en middelen vereisen.
5. Haar falen kan worden geïsoleerd. Het systeem kan expliciet degraderen als die functie niet reageert, via herhaalpogingen, wachtende statussen of uitgesteld werk.
6. Er is voldoende operationeel eigenaarschap. Een team of verantwoordelijke kan de levenscyclus, waarschuwingen, incidenten, beveiliging en compatibiliteit onderhouden.

Een API maakt een module op zichzelf niet tot een microservice. Onafhankelijkheid hangt ook af van data, uitrol, beheer en het vermogen om beslissingen te nemen zonder afhankelijk te zijn van interne implementatiedetails van een andere applicatie.

Kosten die ontstaan bij het scheiden van verantwoordelijkheden

Een functieaanroep faalt anders dan een HTTP-aanroep, een bericht in een wachtrij of een externe query. Na afzondering ontstaan latentie, time-outs, authenticatie tussen diensten, snelheidslimieten, gedeeltelijke onbeschikbaarheid en incompatibele versies.

Ook het consistentiemodel verandert. Als een dienst een handeling bevestigt en een andere de gebeurtenis niet ontvangt of verwerkt, moet je beslissen hoe je de status vaststelt, opnieuw probeert zonder effecten te dupliceren en compenseert wanneer dat nodig is. Gebeurtenisconsumenten moeten idempotent zijn; bijvoorbeeld: een bericht twee keer verwerken mag niet twee documenten uitgeven of twee keer kosten in rekening brengen.

De bedrijfsvoering wordt complexer: correlatie van aanvragen, gedistribueerde tracering, dashboards met meetwaarden, bewaartermijnen voor logboeken, beheer van geheimen, back-upbeleid en hersteltests. Bovendien heeft elk contract compatibiliteitsregels nodig. Optionele velden toevoegen is doorgaans minder verstorend dan semantiek wijzigen, velden verwijderen of een status hergebruiken met een nieuwe betekenis.

Transitiearchitectuur binnen PHP

De minst risicovolle route is modulariseren vóór afzondering. Definieer voor elke functie een applicatielaag, met use cases die opdrachten of query's ontvangen en duidelijk gedefinieerde resultaten teruggeven. Verberg databasetoegang achter repositories of poorten wanneer dat een relevante afhankelijkheid vertegenwoordigt; maak niet van elke klasse een doelloze abstractie.

De rest van de monoliet moet de module gebruiken via haar publieke interne interface, niet via haar entiteiten of tabellen. Als asynchrone meldingen nodig zijn, publiceer dan domein- of integratiegebeurtenissen vanuit een gecontroleerd punt. Een transactioneel outbox-patroon kan helpen om de bedrijfswijziging en de wachtende gebeurtenis in dezelfde transactie te registreren, zodat een later proces die betrouwbaar aflevert.

Deze fase maakt het mogelijk te verifiëren of de grens echt is. Als de interne interface onafgebroken groeit, private objecten van andere modules vereist of in elk use case gedeelde transacties nodig heeft, is zij nog geen sterke kandidaat voor scheiding.

Hoe je de eerste dienstgrens definieert

De eerste dienst moet een gemakkelijk uit te leggen verantwoordelijkheid hebben en beperkt afhankelijk zijn van de kern. Documenteer vier elementen voordat je infrastructuur schrijft:

• Verantwoordelijkheid: welke beslissingen zij neemt en welke er expliciet buiten vallen.
• API of gebeurtenissen: invoer, uitvoer, fouten, authenticatie, tijdslimieten en idempotentie.
• Data-eigenaarschap: wat zij opslaat, welke externe identificatoren zij bewaart en welke informatie zij via contracten opvraagt.
• Compatibiliteit: hoe producenten en consumenten tijdens versiewijzigingen naast elkaar bestaan, inclusief vertraagde berichten.

Vermijd het ontwerpen van een API als spiegel van de tabellen. Een contract moet bedrijfshandelingen of -feiten uitdrukken, niet persistentiedetails blootleggen die latere wijzigingen zullen blokkeren.

Voorbeeld: documentverwerking zonder de backoffice te fragmenteren

Neem een PHP-backoffice die dossiers beheert en documenten moet genereren, valideren en opslaan. In het begin kan de verwerking als interne module bestaan: deze ontvangt een verzoek om een document te genereren, registreert de taak, voert een asynchrone taak uit en werkt een voor de gebruiker zichtbare status bij.

Afzondering wordt redelijk als documentgeneratie zeer andere middelen verbruikt, specifieke conversieafhankelijkheden nodig heeft, eigen pieken ontvangt en kan functioneren met een documentverzoek dat de minimaal benodigde data bevat. De documentdienst zou niet vrijelijk de tabellen van het dossier moeten raadplegen. De backoffice kan een opdracht sturen met een identificator, toepasselijke sjabloon, dataversie en bestemming; het resultaat komt terug als gebeurtenis of opvraagbare status.

Het is daarbij zinvol te verduidelijken dat een sjabloon de uitvoerstructuur definieert, terwijl een model kan verwijzen naar domeindata of naar een AI-systeem. Als AI zou worden ingezet om documenten te classificeren, zouden een afgebakend use case, evaluatie met representatieve data, menselijke beoordeling bij gevoelige beslissingen, gegevensbescherming, kostenbeheersing en een handmatig of op regels gebaseerd alternatief nodig zijn wanneer de leverancier faalt.

Controles vóór afzondering

Behandel afzondering niet als een geïsoleerde technische uitrol. Definieer een gefaseerde activering voor een gecontroleerde subset van handelingen, los van het aankondigen van de wijziging aan alle gebruikers. Behoud een plan voor co-existentie en terugdraaiing terwijl je het gedrag valideert.

• Contracttests tussen producent en consument, naast unit- en integratietests.
• Meetwaarden voor latentie, fouten, herhaalpogingen, wachtende wachtrijen, duplicaten en tijd tot het proces is voltooid.
• Correlatie-identificatoren om een handeling te volgen tussen de monoliet, wachtrijen en dienst.
• Herstelprocedures: veilige heruitvoering, afstemming van statussen, back-up en herstel.
• Expliciete regels voor functionele degradatie wanneer de dienst niet beschikbaar is.
• Een exitcriterium: welk bewijs zal aantonen dat afzondering een concreet probleem heeft verminderd en niet alleen complexiteit heeft verplaatst.

De beste architectuurkeuze is die welke de evolutie van het product beschermt zonder een disproportioneel platform op te leggen. Een modulaire, meetbare en goed afgebakende PHP-monoliet is doorgaans de juiste stap totdat een functie een verifieerbare noodzaak voor onafhankelijkheid aantoont.