Microservices kiezen op basis van onafhankelijke wijzigingen
Onderzoek aparte services als bedrijfsgrenzen, gegevenseigenaarschap en onafhankelijke uitrolbehoeften bij elkaar passen.
Welke wijziging moet onafhankelijk kunnen?
Een toepassing over services verdelen maakt ontwikkeling niet vanzelf onafhankelijk. Moeten dezelfde mensen voor iedere prijsregel alle services samen wijzigen en uitrollen, dan blijft afstemming nodig. Netwerkverzoeken en extra beheertaken komen erbij.
Microsoft noemt onafhankelijke uitrol en eigen verantwoordelijkheid voor gegevens belangrijke kenmerken. Begin daarom volgens ons bij een concrete wijziging: welk bedrijfsdomein moet die kunnen dragen zonder gelijktijdige aanpassingen elders?
Voorbeeld: offertes en orders blijven voorlopig samen
Dit product en deze werkwijze zijn fictief. Eén team beheert offertes, orders en rapporten. Prijsregels veranderen gezamenlijk in offerte en order. Rapportformaten hebben andere wijzigingsbehoeften.
Waargenomen grens in het voorbeeld | Voorlopige keuze | Wat de keuze moet ondersteunen |
|---|---|---|
Offertes en orders delen dezelfde inhoudelijke prijswijziging. | Samen uitrollen, met duidelijke interne modules. | Verantwoordelijkheid en toegang tussen modules zijn expliciet geregeld. |
Rapportformaten kunnen onafhankelijk veranderen. | Een eigen module; een aparte service onderzoeken bij aangetoonde behoefte. | Stabiele gegevensinterface, verantwoordelijk beheer en vereiste actualiteit van gegevens zijn duidelijk. |
In dit plan blijft de toepassing eerst een modulaire monoliet: interne grenzen, gezamenlijke uitrol. Spring Modulith illustreert het onderscheid tussen publieke module-interface en interne uitwerking. Dit beschrijven is ook zinvol zonder dat specifieke hulpmiddel te kiezen.
Neem beheer mee in de keuze
Een aparte rapportageservice zou uitval van zijn gegevensbron moeten opvangen. Iemand moet verantwoordelijk zijn voor uitrol, bewaking en incidentonderzoek. Het team heeft ook regels nodig voor oude en nieuwe interfaceversies tijdens een overgang. Een apart proces alleen voldoet daar niet aan.
Leg de reden voor latere splitsing vast, zoals werkelijk noodzakelijke onafhankelijke uitrol of een belasting die anders behandeld moet worden. Beoordeel koppeling, gegevenstoegang en beheerinspanning opnieuw. Ook gezamenlijk uitgerolde modules kunnen helder gestructureerd zijn. Een goed begrensde service kan gerechtvaardigd zijn voordat de rest wordt gesplitst. Het aantal services meet de kwaliteit van deze keuze niet.
Bronnen
Geschreven door
- Katharina WeberRedacteur software en technologieKatharina Weber verzorgt bij ASES de artikelen over softwareontwikkeling. Ze schrijft over de vragen waar bedrijven mee te maken krijgen bij het kiezen van software, het ontwikkelen van nieuwe toepassingen en het moderniseren van bestaande systemen.
Verder lezen
Alle artikelen
Softwareontwikkeling met ASES
Maatwerksoftware, web- en mobiele apps