foto av national cancer institute på unsplashfigcaption>

veksten av microservice adopsjon har forårsaket en oppblomstring i popularitet av noen tidligere oversett programvare Design Mønstre. Mange av disse mønstrene har blitt utvunnet Fra Eric Evans ‘ Domenedrevet Design, en bok som handler like mye om lagstruktur som det handler om programvarearkitektur.

og av disse mønstrene er Den Avgrensede Konteksten kanskje den viktigste å forstå. Som ingeniører har vi kommet for å vurdere Den Begrensede Konteksten for å være et designmønster for programvarearkitektur. Men det er fordi vi har co-valgt det litt fra sin opprinnelige bruk. Som Brukt Av Evans er Den Begrensede Konteksten like mye et organisasjonsmønster som det er en teknisk.Derfor har jeg kommet for å se Det Begrensede Kontekstmønsteret som en lynchpin i å forstå microservices. Ikke bare hvordan vi bygger dem, men egentlig hvorfor vi bygger dem i utgangspunktet, og hvordan de kan gjøre våre organisasjoner mer vellykkede. Hvis vi forstår Hva Avgrensede Sammenhenger er-hvis vi vedtar Den Avgrensede Konteksttanken både teknisk og organisatorisk – så kan vi virkelig lykkes med å bygge vår mikrotjenestearkitektur.

hvorfor flytte til microservices?

for å begynne, la oss utføre en liten øvelse. Spør deg selv dette spørsmålet: Hvorfor bygger vi mikrotjenester i utgangspunktet?

Ta deg tid til å tenke på det. Hva er fordelene som først kommer til tankene? Hva er de viktigste problemene vi bør håpe å løse? Skriv ned noen svar, bare for å holde deg ærlig.

…

har du svaret ditt? God. Les det tilbake til deg selv. Har du truffet standard tekniske fordeler? Kontinuerlig levering, skalerbarhet, polyglot miljøer, containere og skyer, og alt det gode ting? Stor.

men inkluderte ditt toppsvar noe om å gjøre det mulig for organisasjonen å operere mer effektivt? Det burde det. Fordi å bygge mikrotjenester handler ikke om å realisere tekniske fordeler. Egentlig handler det om å få organisatoriske fordeler. Alt annet er en implementeringsdetalj.

Monolitter = koblet kode og koblede lag

når våre monolitter blir større og større, begynner produktiviteten å avta. Det er minst to hovedgrunner til det.

Å Sette bremsene på vår hastighet

Først bidrar hvert ingeniørteam til en gigantisk kodebase. Som sådan står lagene overfor en stadig økende sannsynlighet for at koden deres vil komme i konflikt med andres kode. For å bidra til å redusere de potensielle problemene dette kan forårsake, innfører vi prosedyrer-kodefrysing — qa-testperioder, frigjøringstog, etc. – det er bokstavelig talt designet for å bremse produktiviteten vår.

selvfølgelig holder disse prosedyrene funksjoner og forbedringer fra å bli distribuert i tide. De skaper også kaos på ingeniørers evne til å fokusere på lagets prioriteringer. Hvis en feil blir funnet i løpet av en testperiode, må det ansvarlige teamet kontekstskifte og fokusere på å løse den feilen. Hvis en alvorlig feil er funnet i produksjonen, må teamet ikke bare fikse feilen, men også hoppe gjennom hoops for å få den distribuert av neste utgivelsestog.

på vakt plikt blir en boondoggle. Hvis noe går galt med vår monolitt, må noen være tilgjengelig-dag eller natt-for å løse problemet. Men hvem? Store organisasjoner med store monolitter står generelt overfor to valg: en hendelsesledelse hvis eneste, triste, beklager jobb i organisasjonen er å svare på problemer forårsaket av andre ingeniørers kode, og finne ut hvordan de skal løses.en roterende vaktplan, hvor hver uke en vilkårlig ingeniør blir tildelt den triste, beklager jobben med å bli ansvarlig for å løse problemer som mest sannsynlig skyldes kode skrevet av en annen ingeniør, i et annet ingeniørteam.

(Mis)organisere våre lag

Monolitter rot med våre organisasjoner på enda en måte. Hele vår organisasjon jobber med det samme, store produktet. Men vi må fortsatt bryte organisasjonen i håndterbare lag. Så vi pleier å se på funksjonelle roller for å finne laggrenser:

dessverre begrenser denne typen organisasjonsstruktur samarbeid. I stedet for å jobbe sammen for å løse det sanne problemet ved hånden (f. eks. hvordan designer, bygger Og vedlikeholder Vi Funksjonen X?) medlemmer av de ulike funksjonsområdene fokuserer bare på sin egen del, metaforisk kaster sitt arbeid over gjerdet når de er ferdige. Potensialet for samarbeid og synergi – hvor den kombinerte kvaliteten på teamets innsats er mye mer enn summen av de enkelte teammedlemmene – går tapt.

det er også rife med flaskehalser. Når vi organiserer våre lag etter funksjonsområde, vil vi naturligvis ha feiljustering i prioriteringer. La oss si at produktledelsen bestemte seg for at vår monoliths betalingsprosess må fornyes. De vil planlegge tid med designteamet for å sette sammen noen mocks. På et tidspunkt vil mocks bli ferdig og overlevert til frontend-teamet for å implementere. Selvfølgelig vil frontend-teamet trenge Apier som skal implementeres av backend-teamet, slik at de blir blokkert til det er fullført. Når backend-teamet prioriterer sitt arbeid på de nye betalingstjenestene, finner det at Det trenger hjelp fra Databaseadministrasjonsteamet (Dba). Som selvfølgelig har sine egne prioriteringer. Så backend-laget vil bli blokkert til EN DBA er frigjort.

på en måte virker denne organisasjonsstrukturen litt som en dårlig utformet, altfor koblet programvarearkitektur… ikke sant?

Microservices = avkoblet kode, frakoblede team

en mikrotjenestearkitektur gjør derimot teamautonomi mulig. Det blir mye lettere å danne lag som er selvstendige, som fungerer effektivt sammen, og som ikke er konstant blokkert av avhengigheter på andre lag.

Team kan ta fullt eierskap over arbeidet sitt, fra design til utvikling til utrulling. Hvert medlem deler ansvaret for å oppnå lagets mål, slik at de blir incentivisert til å delta i mer enn bare «deres del». Jeg har jobbet med team hvor produktledere, designere, front-end, back-end og mobile ingeniører har kommet sammen for å designe produktfunksjoner, noe som gir langt bedre resultater enn det som kunne vært oppnådd av en person.

teamet får ansvar for sine egne gjenstander når de er utplassert i produksjon. Dette fører vanligvis til høyere kvalitetskode som er enklere å feilsøke. Hvorfor det? I motsetning til med en monolit, har lagene en tendens til å ha et helhetlig syn på mikrotjenestene de eier. Så det er mye lettere for teamet å forutse problemer, å legge til god logging og beregninger for å feilsøke problemer når de oppstår, og å gjøre riktig bruk av motstandsmønstre (f.eks.Videre, Siden lagene har en full følelse av eierskap over sitt arbeid, holder tjenestene sine sunne og kjører i produksjon blir mindre om en marerittaktig utgivelsesplan, og mer om å pleie deres opprettelse.

til slutt jobber lagene mot samme mål, på samme tidslinje. Det betyr ikke mer å blokkere en person som de venter på noen i et annet funksjonsområde for å frigjøre.

Vi må være forsettlige om autonomi

Men vi får ikke disse fordelene gratis bare ved å bryte vår monolit inn i mikrotjenester. La oss ta en titt på vår første, naive visning av en microservices arkitektur:

/ div>

hvis vi er som de fleste ingeniører, er vår første ide om en microservice-arkitektur, vel, en haug med microservices. Hver eksponerer EN SLAGS API (ReST, kanskje) for å tillate noen annen tjeneste å lese fra den og skrive til den.når vi får erfaring, lærer vi at ikke alle mikrotjenester tjener samme formål — eller i det minste bør de ikke. Og derfor, mye som vår monolitt hadde blitt arrangert i lag, så vi ordne våre microservices:

på dette punktet har vi definert de forskjellige typer mikrotjenester og applikasjoner som vi ønsker å bygge. Stor. Men vi har fortsatt ikke gjort mye fremgang når det gjelder lagets autonomi. Hver microservice må eies av noen lag. Og så oppstår spørsmålet: hvilke lag vil eie hvilke mikrotjenester?

kryssfunksjonelle team

Vår første, naive tilnærming kan være å organisere teamene våre ved å etterligne vår monolittiske org-struktur:

her ser vi lag (i lilla) organisert etter funksjon: ux design, frontend engineering, backend engineering, data ingeniører, dba, qa, etc.

Dette kan føles riktig, i hvert fall i utgangspunktet. Men la oss ta et skritt tilbake og se på verdien vi prøver å levere til våre kunder. Er det vårt mål å bygge ting som følgende for våre kunder?

• en haug med databaseskjemaer
• en haug med brukergrensesnitt mockups
• en haug med microservices som kan snakke Med En MySQL database?

Egentlig ikke. Det er bare verktøyene vi bruker for å skape verdi for kundene våre. Den faktiske verdien som vi gir våre kunder / brukere kommer i form av funksjoner og funksjonalitet som:

• en produktkatalog for å søke
• en mekanisme for å plassere elementer i en handlekurv og deretter kjøpe dem
• et varslingssystem for å varsle kunder om status for sine kjøp

På Samme måte ønsker Vi Ikke å organisere teamet vårt etter funksjonsområde. I stedet bør vi definere teamene våre etter verdien de skaper for kundene; det vil si på tvers av funksjoner, i (det passende navnet) tverrfunksjonelle team.

med tverrfunksjonelle team jobber alle sammen for å bygge et bestemt produkt eller funksjon, fra start til slutt. Alle på laget har samme mål og prioriteringer, så ingen funksjonsområde er blokkert av en annen. Krever den nye backend API-tjenesten noe databaseutformingsarbeid? Fint; lagets backend ingeniør og DBA kan begge prioritere sitt arbeid sammen.

på sitt beste oppfordrer tverrfunksjonelle team medlemmene til å samarbeide gjennom hver fase av prosjektet. Hvert teammedlem bidrar til den generelle utformingen av funksjonen. Frontend, backend og mobile ingeniører definerer I fellesskap API-kontrakter. Alle tester. Og alle begynner å bli godt bevandret i deres bestemt domene.

og så kan våre teamstrukturer begynne å se slik ut:

det er bedre. Men noe føles fortsatt ikke riktig.

Jada, vi har dannet lag som sannsynligvis vil være mer effektive i å eie produkter. Men vi har fortsatt tatt en top-down tilnærming for å identifisere topologien til mikrotjenester som vår organisasjon har til hensikt å bygge. Vi sitter igjen med en stor samling av gjensidige mikroservices, hvorav de fleste er koblet sammen. Vi har bare tildelt dem til forskjellige lag for å bygge.

dette fører til bekymringer som:

• Hvordan kan Vi lage Apier som vil møte alle nåværende og fremtidige behov som en klient kan ha? Kan vi innkapsle våre data når noen av våre tjenester kan bli kalt av andre teams tjenester?
• Hvor mye tid vil vi kaste bort på å vente på at andre lag skal implementere våre avhengigheter?
• Hvilke feil i våre systemer kan skyldes feil i andre systemer (cascading failures)?
• kan vi kontrollere antall samtaler våre tjenester kan være involvert i? Kan vi sikre at vår organisasjon ikke ender opp med å skape grenseløse synkrone samtaler mellom tjenester, som fører til astronomiske responstider, eller verre (og ja, jeg har sett dette skje) uendelig rekursive samtaler på tvers av tjenester?
• Hva om lagets spesifikke funksjon eller problemplass ikke er godt egnet for den forhåndsplanlagte mikrotjenestetopologien?

Vi trenger enda en annen måte å tenke på. Kanskje finnes det allerede et mønster for oss å følge?

Skriv Inn Den Avgrensede Konteksten

Den Avgrensede Konteksten er et nøkkeldesignmønster som bæres ut av domenedrevet design, ELLER DDD. Å forstå Den Begrensede Konteksten hjelper oss med å danne autonome lag og i tillegg autonome mikroservicearkitekturer.DDD selv beskriver en metodikk for programvareutvikling der enkeltpersoner i en organisasjon jobber sammen for å definere et felles språk. I Sin Bok Domain Driven Design skildrer Eric Evans ofte ingeniører som arbeider med produkteiere for å etablere et avtalt ordforråd for å beskrive ting som produkter, komponenter av produktene, handlinger som et produkt kan utføre (eller kan utføres på produktet), deler av arbeidsflyter, etc. Dette vokabularet omfatter organisasjonens domene.

i mange store organisasjoner blir det imidlertid umulig å definere et enkelt, konsistent ordforråd. I disse tilfellene bryter vi vårt domene inn i underdomener. Eksempler på underdomener kan omfatte:

• Lagerstyring
• Produkt discovery
• Ordrehåndtering
• handlekurver og kassa

som designere, ingeniører, produktsjefer, etc, komme sammen for å bygge ut et underdomene, de danner sin egen måte å tenke og snakke om underdomenet og dets komponenter.

DETTE er HVOR DDD møter tverrfunksjonell lagstruktur. Selv om lagmedlemmene er fra forskjellige funksjonsområder, er de ansvarlige for sitt eget underdomene, og blir til slutt bosatt eksperter. Videre er teamet ansvarlig for å bestemme hvilke artefakter — mikrotjenester, webapplikasjoner, mobilapper — databaser og tilhørende infrastruktur-som trengs for å bringe underdomenet til liv og til organisasjonens kunder.

Vi kan tenke på laget og dets gjenstander som bestående av En Begrenset Kontekst.

Definere Den Avgrensede Konteksten

Mens Evans diskuterer Avgrensede Sammenhenger ofte i sin bok, definerer Han egentlig ikke mønsteret eksplisitt. Så jeg vil forsøke å gjøre det her:

Begrenset Kontekst:Et internt konsistent system med nøye utformede grenser som formidler hva som kan komme inn i systemet, og hva som kan gå ut av det.

med andre ord representerer En Avgrenset Kontekst en kontekst — i hovedsak et system som innkapsler kooperative komponenter — med klart definerte grenser som styrer hva som kan komme inn i systemet, og hva som kan gå ut av det.

celler (de små tingene som samlet utgjør alle levende vesener) gir en fin analogi. Innenfor en celle er alle slags komponenter (kjernen, ribosomer, cytoplasma, cytoskeletoner, etc) som alle er innkapslet i selve cellen. Rundt hver celle er imidlertid en membran som fungerer som barrieren mellom cellens indre og resten av organismen. Membranen beskytter cellen fra sitt miljø, tillater spesifikke næringsstoffer å komme inn i det, og tillater ulike biprodukter å forlate.

I samme vene består En Avgrenset Kontekst av en rekke komponenter (mikrotjenester, webapplikasjoner, mobilapper, databaser, meldingskøer osv.). Det fungerer også som en logisk barriere som innkapsler disse komponentene. Internt kan komponentene kobles sammen, og kan fritt sende data til hverandre. Men Avgrenset Sammenheng bidrar til å håndheve løs kopling eksternt, definere eksplisitte punkter hvor:eksterne data kan komme inn (kanskje via forbruker som abonnerer på Et Kafka-emne)

interne data kan gå ut (kanskje via et Annet Kafka-emne, eller via EN WELL-design GET API, nøye utformet for å skjule eventuelle interne systemdetaljer)

en Begrenset Kontekst representerer også sitt tverrfunksjonelle team. Teamet består av ulike teammedlemmer(designere, frontend / backend / mobile ingeniører, produktledere, data ingeniører og QA ingeniører, etc). Internt arbeider disse medlemmene sammen mot de samme konsekvente målene. Videre er disse lagmedlemmene (eller bør være) innkapslet slik at de har minimal avhengighet av andre lag.Så i stedet for å starte på et organisasjonsnivå og definere alle applikasjonene og mikrotjenestene vi forventer å bygge, bygger vi lag rundt underdomenene våre, slik at de lagene kan vokse sine underdomener og definere hva som må bygges. Gjort riktig, har vi en tendens til å se ulike Avgrensede Sammenhenger i organisasjonen som vokser organisk, snarere enn som stive, forhåndsdefinerte strukturer.

Implikasjoner på å bryte monolitten

Conways Lov forteller oss at organisasjoner designer programvaresystemer som etterligner organisasjonens kommunikasjonsstruktur. Det viser seg ofte å være sant, så vi bør være gjennomtenkte om hvordan vi strukturerer organisasjonen vår når vi begynner å bygge mikrotjenester.

Faktisk, nå, et bilde skal dukke opp i tankene dine. Når vi beveger oss fra monolitt til mikrotjenester, bør vi begynne å tenke vertikalt (dele monolitten med underdomenene) i stedet for horisontalt (dele monolitten med funksjonelle lag).

vær å dele ting ikke som vi gjør til venstre, men som vi gjør til høyre

med andre ord, bør vi ikke starte med å erstatte monoliths datatilgangslag med datamikroservices. Snarere bør vi begynne med å dele ut en hel funksjon(for eksempel betalingsprosessen, eller kanskje produktsøk). Hver funksjon vil representere En Avgrenset Kontekst. Og hver vil bli delt ut av et dedikert tverrfunksjonelt team.

Videre bør teamet fokusere på sin oppgave, som er å enten:

• trofast gjenskape eksisterende funksjonalitet,
• eller (bedre) å bygge en helt ny, forbedret opplevelse for sine kunder.

som en del av prosessen, bør teamet utforme systemet som er best egnet for bestrebelse.

for eksempel kan vi bestemme oss for å skille vår produktsøkfunksjonalitet ut av vår monolitt. Produktsøkteamet kan til slutt designe et system som inkluderer:Kafka forbrukere som lytter til en rekke Eksterne Kafka emner å oppdatere sin egen interne system of record (SoR) for produkter.en Annen Kafka-forbruker som lytter til det interne emnet og oppdaterer En Elastisk Søkeindeks

Et GraphQL-endepunkt for freeform-søk som spør Elastisk Søk

Et ReST-endepunkt som henter individuelle produkter ETTER ID

en nydesignet webapplikasjon som bruker disse endepunktene for å tillate kunder å søke etter produkter og utforske produktdetaljer

et lignende sett med skjermer I våre mobile apps som bruker disse endepunktene

En Kafka utgiver Som Skyver Meldinger, representerer forskjellige spørringer utført av kunder, til et eksternt Kafka-emne, for bruk av enhver annen avgrenset kontekst (for eksempel analyse) som kan være interessert

hva utformingen av vårt produkt-søk avgrenset kontekst, innkapslet i rødt, kan se ut

som vi begynner peeling av flere og flere vertikale deler av vår monolitt, andre lag bygge ut sine egne avgrenset sammenhenger. Disse Avgrensede Sammenhenger kan ende opp med å se ganske forskjellig fra hverandre.

hvordan best bygge løse sin oppgave for hånden

legg merke til at komponenter innenfor en gitt avgrenset kontekst kan være tett koblet; vi holder imidlertid våre avgrensede sammenhenger koblet fra hverandre. I vårt eksempel skjer all kommunikasjon mellom Avgrensede Sammenhenger ved å sende meldinger via En Kafka – meldingskø. Det er viktig at vi unngår synkrone forespørsler / svaranrop mellom Begrensede Sammenhenger.

dette gjelder også med det som er igjen av monolitten. Vi vil absolutt ikke ha tett kobling mellom våre nye mikrotjenester og vår arvmonolitt. Så når vi skreller deler av monolitten bort, utnytter vi meldingspassering for å tillate de resterende delene å kommunisere med våre nye Avgrensede Sammenhenger.

Reality check på alt dette avkobling

På dette punktet, kan vi spørre oss selv om det er virkelig mulig å holde Våre Avgrensede Sammenhenger frakoblet.

i den virkelige verden, kan vi virkelig holde våre lag beskyttet mot eksterne avhengigheter? Vil det aldri være tilfeller der et lag må blokkeres av et annet lag for å få sitt arbeid gjort?

og kan vi faktisk lage tjenestearkitekturer for våre underdomener som er helt avkoblet fra andre underdomener? Er det virkelig ikke behov for et program i En Begrenset Kontekst for å synkront ringe en tjeneste i en annen?

i virkeligheten kan det være umulig å holde Våre Avgrensede Sammenhenger 100% avkoblet. Men vi kan komme nærmere, mye nærmere enn de fleste av oss kanskje tror.

real-life arkitekturer

La oss begynne med å se på avkoblede arkitekturer. Ofte kjøper vi inn feilen at en gitt type data skal leve på nøyaktig ett sted, og at ethvert annet system må direkte ringe til det ene stedet for å få tilgang til dataene.

vi refererer til dette som å tildele En Enkelt Kilde Til Sannhet (SSoT) til våre data. Men som beskrevet i denne artikkelen som dissekerer ideen Om SSoTs, er selve begrepet stort sett et anti-mønster. I stedet bør De Fleste Avgrensede Sammenhenger lagre sin egen lokale kopi av data som de trenger å bruke.

Dette er eksemplifisert ved Vår Produkt-Søk Avgrenset Kontekst fra forrige avsnitt. Denne Avgrensede Konteksten er selvsagt avhengig av organisasjonens produktkatalogdata. Men oddsen er at dataene genereres i en Annen Begrenset Kontekst (vi kaller Det Produktoppføringsbegrenset Kontekst).

Vår første (naive) tilnærming kan være å eksponere En ReST API Fra Produkt-Entry Avgrenset Kontekst og tvinge tjenestene i Produkt-Søk Avgrenset Kontekst for å kalle DET API. Men vi kan gjøre det bedre. Vi kan i stedet holde systemene frakoblet ved å publisere endringene Som Er gjort Av Produktinngangstjenestene på Kafka. Våre Produkt-Søk Kafka forbrukere deretter plukke opp disse meldingene og oppdatere Produkt – søk databaser.

merk at de to avgrensede kontekstene til slutt er konsistente. Dette betyr at det vil være korte perioder hvor et gitt stykke data kan være inkonsekvent Mellom Produktoppføring og Produktsøk. For Eksempel, hvis prisen På Hvite Wombat Widgets er hevet fra $1,99 til $2.49, vil det være en kort periode (ofte et spørsmål om sekunder hvis ikke millisekunder) der det er en 50¢ forskjell I Hvit Wombat Widget pris over de to Avgrensede Sammenhenger.

dette fører til de virkelige tilfellene når vi ikke har noe annet alternativ enn å parbegrensede Sammenhenger. I noen tilfeller er eventuell konsistens ikke akseptabel. For eksempel, før en kunde kan fullføre sitt online kjøp, må vi kanskje sørge for at hvert element i handlekurven faktisk er tilgjengelig i det øyeblikket. Selv da kan vi ofte minimere koblingen mellom de To Avgrensede Sammenhenger.

våre interaksjoner kan se slik ut:

• som kunden bruker Product-Search UI for å finne produkter, Brukes Product-Search databaser til å hente informasjon (for eksempel stiler, kundeanmeldelser, priser, etc.) om produktene
• Selv når kunden begynner betalingsprosessen, bruker vi Fortsatt Produktsøkdatabasene for å hente informasjonen som må vises.
• Til Slutt, når kunden klikker på den endelige «Complete Purchase» – knappen, gjør vi et enkelt synkront anrop til Produktoppføringen Begrenset Kontekst for å validere varenes tilgjengelighet før du fullfører kjøpet.

Et annet vanlig eksempel som krever umiddelbar konsistens knyttet til autorisasjon. I mange systemer må sikkerhetstokener hentes eller valideres på hver forespørsel. I disse tilfellene må vi sannsynligvis tillate At Våre Avgrensede Sammenhenger kaller en annen, sikkerhetsorientert Avgrenset Kontekst.

virkelige org-strukturer

hva med selvstendige, tverrfunksjonelle team? Hvor mulig er det i den virkelige verden?i virkeligheten er det en prosess med kontinuerlig bevegelse mot helt selvhjulpne lag. Sjelden vil vi noen gang nå 100% autonomi med våre lag. Men hvis vi starter med å organisere våre lag intelligent, og gjenkjenne og svare på flaskehalser som oppstår, kan vi komme nær.for det første bør vi maksimere våre vertikale, tverrfunksjonelle lag og minimere antall horisontale, enkeltfunksjonelle lag. Det betyr å motstå trangen til å danne såkalte «kjerne» – lag – hvis oppgave er å bygge felles datatjenester som forbrukes av andre produktorienterte lag – og i stedet danne våre lag rundt forretningsverdien de vil gi.Mange organisasjoner tiptoe mot dette målet, først danner domene-orienterte team av produktsjefer, og front-end og back-end ingeniører. Det er en start. Men hvem andre skal disse lagene inkludere? Eksakt medlemskap kan variere på tvers av ulike lag med ulike behov. Men vi bør vurdere ting som:

• Hvis vårt team har front-end ingeniører, så oddsen er at de skal jobbe tett med en grafisk designer som er dedikert til domenet.
• mobile ingeniører — ofte plassert i sitt eget område av organisasjonen-bør inkluderes for domener med en mobil komponent.I sin opplysende artikkel om datamasker beklager Zhamak Dehghani at dataingeniører ofte utelukkes fra tverrfunksjonelle lag — til skade for dataingeniørene og de tverrfunksjonelle lagene selv.

Når vi har bestemt medlemskapet til lagene våre, bør vi passe på flaskehalser. Er det noen andre lag som vanligvis blokkerer våre tverrfunksjonelle teams produktivitet?

for eksempel har mange organisasjoner et dedikert sikkerhetsteam. Dette er en god praksis, selvfølgelig; organisasjoner trenger en sammenhengende sikkerhetsstrategi, og en måte å sikre styring over den strategien. Det er imidlertid også vanlig for team å stoppe arbeidet på ulike stadier for å tillate sikkerhetsvurderinger av arbeidet sitt. Selv i de beste situasjoner etablerer dette veisperringer for våre team som en rutine en forretningspraksis. Videre vil det ofte føre til at team må skrape hele eller deler av arbeidet og starte på nytt, da de avdekker sikkerhetskrav som ikke var oppfylt.

dette er tydelig en dårlig lukt. Men hvordan kan vi håndheve organisasjonens sikkerhetsstandarder samtidig som teamene forblir autonome og produktive?

Vi kan gjøre dette ved å legge til sikkerhetsingeniører i våre tverrfaglige team. Det er tre tilnærminger vi kan ta:

• hvis vi er heldige nok til å ha et relativt stort sikkerhetsteam, kan vi tildele hvert tverrfunksjonelt team en heltids sikkerhetsingeniør (SE).
• med mindre sikkerhetsteam kan HVER SE tilordnes en rekke tverrfunksjonelle lag på deltid. Dette vil fortsatt tillate SEs å forstå lagets mål og design, og å jobbe med teamet for å overholde organisasjonens sikkerhetsstandarder gjennom hele prosessen.
• hvis vi ikke har nok sikkerhetsressurser for enten vi kan bevege seg i motsatt retning. I stedet for å bringe medlemmer av sikkerhetsteamet inn i våre tverrfunksjonelle team, kan vi bringe medlemmer av de tverrfunksjonelle teamene ut til sikkerhetsteamet. Hvert tverrfunksjonelt team vil utpeke en eller to sikkerhetsrepresentanter. Representantene vil med jevne mellomrom møte sikkerhet og holdes oppdatert med organisasjonens sikkerhetskrav og standarder. De kan ikke være sikkerhetseksperter selv. Men de vil være i stand til å tjene rollen som en sikkerhetsingeniør, slik at deres lag overholder organisasjonens sikkerhetspraksis.

Guilds

Dette dovetails inn i et annet organisasjonsmønster som har fått trekkraft: guilds. Guildmodellen ble født fra den tverrfunksjonelle teammodellen. Av deres natur er disse lagene befolket med medlemmer som spesialiserer seg på ulike funksjoner. Likevel er det ofte fornuftig for folk som spesialiserer seg på en bestemt funksjon å møte sammen også; for eksempel å:

• Finpusse sine ferdigheter og lære av hverandre
• Oppdag og etablere beste praksis for deres spesielle funksjon
• Avhengig av funksjonen, skape selskapet standarder og krav

Vår siste sikkerhetsløsning effektivt dannet en «security guild». Teammedlemmer jobbet primært med sine vertikale lag; men med jevne mellomrom ville noen av dem møte sikkerhets «guild» for å diskutere organisasjonens sikkerhetspraksis og standarder.

guildmodellen fungerer også spesielt godt når det gjelder programvarearkitektur. Spesielt med en mikrotjenestearkitektur er det nødvendig med et visst nivå av organisasjonsomfattende teknisk styring. Likevel har en gruppe arkitekter som sitter i et metaforisk elfenbenstårn, som deler ut regler til lag, generelt motproduktivt. I stedet kan senior / lead ingeniører fra våre tverrfunksjonelle team med jevne mellomrom møtes i en arkitektur guild. Der kan de ta opp problemer fra sine lag, og utarbeide løsninger, og etablere pattens og standarder.

Eksempler på vertikal tverrfunksjonelle lag, supplert med horisontale guilds

guilds kan også utvides til nesten alle andre funksjoner også. Tross alt vil vi at designere skal utvikle og jobbe fra en felles UI-stilguide. Vi ønsker at våre frontend ingeniører til å bruke de samme UI elementer. QA ingeniører bør være på linje med hvordan testing er gjort i våre organisasjoner. Og produktledere bør være synkronisert med organisasjonens samlede produkt veikart.

Ta det hele sammen

Flytte til mikrotjenester kan dramatisk forbedre produktiviteten til våre lag. Men vi må forstå hvordan vi kan dra nytte av en mikrotjenestearkitektur for å komme oss dit. Av alle designmønstre og konsepter som relaterer seg til mikrotjenester, Er Den Begrensede Konteksten uten tvil den viktigste Som gir oss den forståelsen.

Med en solid forståelse av Den Begrensede Konteksten forstår vi det:

• vår organisasjonsstruktur og vår tekniske arkitektur går hånd i hånd
• våre produktorienterte team bør ha minimal avhengigheter på andre lag, akkurat som systemene de bygger skal kobles fra andre systemer

generelt, omfavner Den Avgrensede Konteksten setter i tankegangen at vi trenger å lykkes med vår microservices arkitektur. Sørg for at du forstår dette viktige mønsteret før du legger ut på din microservices reise!