wzrost popularności mikroserwisów spowodował odrodzenie popularności niektórych wcześniej pomijanych wzorców projektowania oprogramowania. Wiele z tych wzorców zostało wydobytych z książki Erica Evansa Domain Driven Design, która jest tak samo o strukturze zespołu, jak o architekturze oprogramowania.
i z tych wzorców, Ograniczony kontekst jest chyba najważniejszy do zrozumienia. Jako inżynierowie uznaliśmy Ograniczony kontekst za wzorzec projektowania architektury oprogramowania. Ale to dlatego, że wybraliśmy go nieco z jego pierwotnego użycia. Użyty przez Evansa, Ograniczony kontekst jest tak samo wzorcem organizacyjnym, jak i technicznym.
dlatego przyszedłem zobaczyć Ograniczony wzorzec kontekstu jako lincz w zrozumieniu mikroserwisów. Nie tylko jak je budować, ale przede wszystkim dlaczego je budujemy i jak mogą sprawić, że nasze organizacje odniosą większy sukces. Jeśli zrozumiemy, czym są ograniczone konteksty-jeśli przyjmiemy sposób myślenia związany z ograniczonym kontekstem zarówno technicznie, jak i organizacyjnie — możemy naprawdę odnieść sukces w budowaniu naszej architektury mikroserwisów.
po co przenosić się na mikroserwisy?
na początek wykonajmy małe ćwiczenie. Zadaj sobie to pytanie: Dlaczego w ogóle budujemy mikroserwisy?
zastanów się chwilę. Jakie są korzyści, które przychodzą na myśl? Jakie są główne problemy, które powinniśmy rozwiązać? Zapisz kilka odpowiedzi, żeby być szczerym.
…
masz odpowiedź? Dobrze. Przeczytaj sobie. Czy osiągnąłeś standardowe korzyści techniczne? Ciągłe dostarczanie, skalowalność, środowiska poliglotyczne, kontenery i chmury i to wszystko? Świetnie.
ale czy Twoja najlepsza odpowiedź zawierała coś o umożliwieniu Twojej organizacji bardziej wydajnego działania? Powinno. Ponieważ budowanie mikroserwisów nie polega na osiąganiu korzyści technicznych. Naprawdę chodzi o uzyskanie korzyści organizacyjnych. Wszystko inne jest szczegółem implementacji.
Monoliths = coupled code and coupled teams
w miarę jak nasze monolity stają się coraz większe, produktywność zaczyna słabnąć. Istnieją co najmniej dwa główne powody tego.
hamując naszą prędkość
Po pierwsze, każdy zespół inżynierów przyczynia się do jednego gigantycznego kodu. W związku z tym zespoły mają coraz większe prawdopodobieństwo, że ich kod będzie kolidował z kodem innych osób. Aby pomóc złagodzić potencjalne problemy, które może to spowodować, Wprowadzamy procedury-zamrożenie kodu, okresy testowania jakości, pociągi zwalniające itp. – które dosłownie spowalniają naszą produktywność.
oczywiście procedury te zapobiegają terminowemu wdrożeniu funkcji i ulepszeń. Sieją również spustoszenie w zdolności inżynierów do skupienia się na priorytetach swoich zespołów. Jeśli błąd zostanie znaleziony podczas okresu testowego, odpowiedzialny zespół musi zmienić kontekst i skupić się na jego rozwiązaniu. Jeśli w produkcji pojawi się poważny błąd, zespół musi nie tylko go naprawić, ale także przeskoczyć przez obręcze, aby go wdrożyć do następnego pociągu wydania.
dyżur dyżurny staje się boondoggle. Jeśli coś pójdzie nie tak z naszym monolitem, ktoś musi być dostępny-w dzień lub w nocy-aby rozwiązać problem. Ale kto? Duże organizacje z dużymi monolitami mają zazwyczaj do czynienia z dwoma wyborami:
- zespół zarządzający incydentami, którego jedyną, smutną i smutną pracą w organizacji jest reagowanie na problemy spowodowane przez KOD innych inżynierów i wymyślanie, jak je rozwiązać.
- rotacyjny harmonogram dyżurów, w którym co tydzień jakiś arbitralny inżynier otrzymuje smutną, smutną pracę polegającą na stawaniu się odpowiedzialnym za rozwiązywanie problemów, które najprawdopodobniej są spowodowane przez kod napisany przez innego inżyniera, w innym zespole inżynierskim.
(źle)organizacja naszych zespołów
Monolity w inny sposób mieszają się z naszymi organizacjami. Cała nasza organizacja pracuje nad tym samym, dużym produktem. Ale nadal musimy podzielić organizację na zarządzalne zespoły. Mamy więc tendencję do szukania ról funkcjonalnych, aby znaleźć granice zespołu:
niestety taka struktura organizacyjna ogranicza współpracę. Zamiast pracować razem, aby rozwiązać prawdziwy problem (np. jak zaprojektować, zbudować i utrzymać funkcję X?) członkowie różnych obszarów funkcjonalnych po prostu skupiają się na swojej części, metaforycznie wyrzucając swoją pracę za ogrodzenie, gdy są gotowe. Potencjał współpracy i synergii – gdzie łączna jakość pracy zespołu jest znacznie większa niż suma poszczególnych członków zespołu — zostaje utracony.
jest też pełno wąskich gardeł. Kiedy organizujemy nasze zespoły według obszarów funkcjonalnych, będziemy naturalnie mieć niedopasowanie priorytetów. Załóżmy, że zespół zarządzający produktem zdecydował, że proces realizacji transakcji w monolith wymaga modernizacji. Zaplanują czas z zespołem projektowym, aby stworzyć jakieś kpiny. W pewnym momencie mocki zostaną ukończone i przekazane zespołowi frontend do wdrożenia. Oczywiście zespół frontendowy będzie potrzebował API do wdrożenia przez zespół backendowy, więc będą one blokowane, dopóki nie zostaną ukończone. Gdy zespół zaplecza nada priorytet swojej pracy nad nowymi usługami kasowymi, stwierdzi, że potrzebuje pomocy zespołu dba (Database Administration). Co oczywiście ma swoje priorytety. Tak więc zespół backend zostanie zablokowany, dopóki DBA nie zostanie uwolniony.
w pewnym sensie ta struktura organizacyjna wydaje się trochę jak źle zaprojektowana, nadmiernie sprzężona architektura oprogramowania… prawda?
Microservices = oddzielony kod, oddzielone zespoły
natomiast Architektura mikroserwisów umożliwia autonomię zespołu. O wiele łatwiej jest tworzyć zespoły, które są samodzielne, efektywnie ze sobą współpracują i które nie są stale blokowane przez zależności od innych zespołów.
zespoły mogą przejąć pełną odpowiedzialność za swoją pracę, od projektu przez rozwój po wdrożenie. Każdy członek bierze udział w odpowiedzialności za osiągnięcie celu swojego zespołu, dzięki czemu staje się zachęcony do udziału w czymś więcej niż tylko „swoją częścią”. Pracowałem z zespołami, w których menedżerowie produktu, projektanci, inżynierowie front-end, back-end i mobilni spotkali się, aby zaprojektować funkcje produktu, uzyskując znacznie lepsze wyniki niż jedna osoba.
zespół przejmuje odpowiedzialność za własne artefakty po ich wdrożeniu do produkcji. To zazwyczaj prowadzi do wyższej jakości kodu, który jest łatwiejszy do rozwiązywania problemów. Dlaczego? W przeciwieństwie do monolitu, zespoły mają tendencję do holistycznego spojrzenia na mikroserwisy, które posiadają. Tak więc o wiele łatwiej jest zespołowi przewidywać problemy, dodawać dobre rejestrowanie i dane, aby rozwiązywać problemy, gdy się pojawią, oraz odpowiednio wykorzystywać wzorce odporności (np. próby wielokrotne, wyłączniki i awaryjne itp.), aby w pierwszej kolejności uniknąć problemów.
Co więcej, ponieważ zespoły mają pełne poczucie odpowiedzialności za swoją pracę, dbanie o zdrowie i sprawność swoich usług w produkcji staje się mniej o koszmarny harmonogram wydawniczy, a bardziej o pielęgnowanie ich twórczości.
wreszcie, zespoły pracują nad tym samym celem, na tej samej osi czasu. Oznacza to koniec z blokowaniem jednej osoby, ponieważ czekają, aż ktoś w innym obszarze funkcjonalnym się zwolni.
musimy być świadomi autonomii
ale nie otrzymujemy tych korzyści za darmo po prostu przez rozbicie naszego monolitu na mikroserwisy. Spójrzmy na nasz pierwszy, naiwny widok architektury mikroserwisów:
jeśli jesteśmy jak większość inżynierów, naszą początkową ideą architektury mikroserwisów jest, cóż, masa mikroserwisów. Każdy z nich udostępnia jakiś rodzaj API (być może ReST), aby umożliwić dowolnej innej usłudze odczytywanie z niego i zapisywanie do niego.
w miarę zdobywania doświadczenia dowiadujemy się, że nie wszystkie mikrousługi służą temu samemu celowi — a przynajmniej nie powinny. W związku z tym, podobnie jak nasz monolit został ułożony warstwowo, więc układamy nasze mikroserwisy:
w tym momencie zdefiniowaliśmy różne typy mikrousług i aplikacji, które chcemy zbudować. Świetnie. Ale nadal nie poczyniliśmy większych postępów w zakresie autonomii zespołu. Każda mikrousługa musi być własnością jakiegoś zespołu. I tak powstaje pytanie: które zespoły będą posiadać jakie mikroserwisy?
Cross functional teams
naszym pierwszym naiwnym podejściem może być zorganizowanie naszych zespołów poprzez naśladowanie naszej monolitycznej struktury org:
tutaj widzimy zespoły (w Kolorze Fioletowym) zorganizowane według funkcji: projektowanie UX, Inżynieria frontend, Inżynieria backendu, inżynierowie danych, DBAs, QA itp.
To może być właściwe, przynajmniej na początku. Ale cofnijmy się o krok i spójrzmy na wartość, którą staramy się dostarczać naszym klientom. Czy naszym celem jest budowanie takich rzeczy dla naszych klientów?
- Banda schematów baz danych
- Banda makiet interfejsu użytkownika
- Banda mikroserwisów, które mogą rozmawiać z bazą danych MySQL?
nie bardzo. To tylko narzędzia, dzięki którym tworzymy wartość dla naszych klientów. Rzeczywista wartość, którą zapewniamy naszym klientom / użytkownikom, ma postać funkcji i funkcjonalności, takich jak:
- katalog produktów do wyszukiwania
- mechanizm umieszczania artykułów w koszyku, a następnie ich zakupu
- system powiadomień ostrzegających klientów o statusie ich zakupów
podobnie nie chcemy organizować naszego zespołu według obszaru funkcjonalnego. Powinniśmy raczej zdefiniować nasze zespoły przez wartość, którą tworzą dla klientów; to znaczy w różnych funkcjach, w (trafnie nazwanych) zespołach międzyfunkcyjnych.
dzięki zespołom funkcjonalnym, wszyscy pracują razem, aby zbudować konkretny produkt lub funkcję, od początku do końca. Każdy członek zespołu ma te same cele i priorytety, więc żaden obszar funkcjonalny nie jest blokowany przez innego. Czy nowa usługa backend API wymaga pracy przy projektowaniu bazy danych? Dobrze; inżynier zaplecza zespołu i DBA mogą nadać priorytet swojej pracy razem.
w najlepszym przypadku zespoły funkcjonalne zachęcają członków do współpracy w każdej fazie projektu. Każdy członek zespołu przyczynia się do ogólnego projektu funkcji. Inżynierowie Frontend, backend i mobile wspólnie definiują umowy API. Każdy testuje. I każdy zaczyna być dobrze zorientowany w swojej dziedzinie.
i tak struktury naszego zespołu mogą wyglądać mniej więcej tak:
tak lepiej. Ale nadal coś jest nie tak.
oczywiście, stworzyliśmy zespoły, które prawdopodobnie będą bardziej skuteczne w posiadaniu produktów. Nadal jednak stosujemy podejście odgórne, aby zidentyfikować topologię mikrousług, które nasza organizacja zamierza zbudować. Pozostaje nam duży zbiór współzależnych mikroserwisów, z których większość jest ze sobą połączona. Po prostu przydzieliliśmy je do różnych zespołów do budowy.
prowadzi to do problemów takich jak:
- Jak możemy stworzyć API, które spełnią wszystkie obecne i przyszłe potrzeby każdego klienta? Czy możemy hermetyzować nasze dane, gdy którakolwiek z naszych usług może zostać wywołana przez inne usługi zespołu?
- ile czasu będziemy tracić na oczekiwanie na wdrożenie naszych zależności przez inne zespoły?
- jakie awarie naszych systemów mogą być spowodowane awariami w innych systemach (awarie kaskadowe)?
- czy możemy kontrolować liczbę połączeń, w które mogą być zaangażowane nasze usługi? Czy możemy zapewnić, że nasza organizacja nie zakończy tworzenia bezgranicznych synchronicznych połączeń między usługami, co prowadzi do astronomicznych czasów odpowiedzi lub co gorsza (i tak, widziałem to) nieskończenie rekurencyjnych połączeń między usługami?
- co jeśli specyfika naszego zespołu lub przestrzeń problemowa nie jest dobrze dostosowana do wcześniej zaplanowanej topologii mikroserwisów?
potrzebujemy jeszcze innego sposobu myślenia. Być może istnieje już jakiś wzór do naśladowania?
wprowadź Ograniczony kontekst
Ograniczony kontekst jest kluczowym wzorcem projektowym opartym na domain driven design, czyli DDD. Zrozumienie ograniczonego kontekstu pomaga nam tworzyć autonomiczne zespoły, a tym samym autonomiczne architektury mikrousług.
DDD sam opisuje metodologię tworzenia oprogramowania, w której jednostki w organizacji pracują razem, aby zdefiniować wspólny język. W swojej książce Domain Driven Design Eric Evans często przedstawia inżynierów pracujących z product owners w celu ustalenia uzgodnionego słownictwa opisującego takie rzeczy, jak produkty, składniki produktów, działania, które produkt może wykonać (lub może być wykonany na produkcie), Części przepływów pracy itp. Słownictwo to obejmuje domenę organizacji.
w wielu dużych organizacjach jednak zdefiniowanie jednego, spójnego słownictwa staje się niewykonalne. W takich przypadkach dzielimy naszą domenę na subdomeny. Przykładami subdomen mogą być:
- Zarządzanie zapasami
- odkrywanie produktów
- zarządzanie zamówieniami
- koszyki i kasa
projektanci, inżynierowie, menedżerowie produktów itp.spotykają się, aby zbudować subdomenę, tworzą swój własny sposób myślenia i mówienia o subdomenie i jej komponentach.
w tym miejscu DDD spotyka się z funkcjonalną strukturą zespołu. Chociaż członkowie zespołu pochodzą z różnych obszarów funkcjonalnych, są odpowiedzialni za własną subdomenę, ostatecznie stają się ekspertami rezydentami. Ponadto zespół jest odpowiedzialny za określenie, które artefakty-mikroserwisy, aplikacje internetowe, aplikacje mobilne, bazy danych i powiązana Infrastruktura — są potrzebne do ożywienia subdomeny i klientów organizacji.
możemy myśleć o zespole i jego artefaktach jako o ograniczonym kontekście.
Definiowanie ograniczonego kontekstu
podczas gdy Evans często omawia ograniczone konteksty w swojej książce, tak naprawdę nie definiuje wprost wzorca. Postaram się to zrobić tutaj:
:
wewnętrznie spójny system z starannie zaprojektowanymi granicami, które pośredniczą w tym, co może wejść do systemu, a co może z niego wyjść.
innymi słowy, Ograniczony kontekst reprezentuje kontekst — zasadniczo system, który zawiera komponenty współpracujące — z jasno określonymi granicami, które regulują to, co może wejść do systemu, a co może z niego wyjść.
komórki (te małe rzeczy, które zbiorowo tworzą wszystkie żywe istoty) oferują miłą analogię. W komórce znajdują się wszelkiego rodzaju składniki (jądro, rybosomy, cytoplazma, cytoszkielety itp.), które są zamknięte w samej komórce. Otaczająca każdą komórkę jest jednak błona, która działa jako bariera między wewnętrznymi komórkami a resztą organizmu. Membrana chroni komórkę przed otoczeniem, pozwala na dostanie się do niej określonych składników odżywczych i pozwala na opuszczenie różnych produktów ubocznych.
w tym samym duchu Ograniczony kontekst składa się z różnych komponentów (mikroserwisów, aplikacji internetowych, aplikacji mobilnych, baz danych, kolejek komunikatów itp.). Służy również jako bariera logiczna, która zawiera te komponenty. Wewnętrznie komponenty mogą być sprzężone i mogą swobodnie przekazywać dane do siebie. Ale ograniczony kontekst pomaga wymuszać luźne sprzężenie Na Zewnątrz, definiując wyraźne punkty, w których:
- dane zewnętrzne mogą wejść (być może przez konsumenta subskrybowanego do tematu Kafki)
- dane wewnętrzne mogą wyjść (być może przez inny temat Kafki lub przez dobrze zaprojektowane API GET, starannie wykonane, aby ukryć wszelkie wewnętrzne szczegóły systemu)
Ograniczony kontekst reprezentuje również jego Wielofunkcyjny zespół. Zespół składa się z różnych członków zespołu (projektanci, inżynierowie frontend/backend/mobile, menedżerowie produktów, inżynierowie danych i inżynierowie QA itp.). Wewnętrznie członkowie ci współpracują w celu osiągnięcia tych samych spójnych celów. Co więcej, członkowie zespołu są (lub powinni być) zamknięci w taki sposób, aby mieli Minimalne zależności od innych zespołów.
więc zamiast zaczynać od poziomu organizacyjnego i definiować wszystkie aplikacje i mikroserwisy, które chcemy zbudować, budujemy zespoły wokół naszych poddomen, umożliwiając tym zespołom rozwijanie swoich poddomen i definiowanie tego, co należy zbudować. Właściwie wykonane, mamy tendencję do postrzegania różnych ograniczonych kontekstów w organizacji jako rosnących organicznie, a nie jako sztywnych, predefiniowanych struktur.
implikacje na złamanie monolitu
prawo Conwaya mówi nam, że organizacje projektują systemy oprogramowania, które naśladują strukturę komunikacji ich organizacji. To często okazuje się prawdą, więc powinniśmy być przemyślani o tym, jak organizujemy naszą organizację, gdy zaczynamy budować mikroserwisy.
rzeczywiście, do tej pory obraz powinien pojawić się w twoim umyśle. Przechodząc od monolitu do mikroserwisów, powinniśmy zacząć myśleć pionowo (dzieląc monolit przez jego subdomeny) zamiast poziomo (dzieląc monolit przez jego warstwy funkcjonalne).
innymi słowy, nie powinniśmy zaczynać od zastąpienia warstwy dostępu do danych monolitu mikroserwisami danych. Zamiast tego powinniśmy zacząć od podzielenia całej funkcji (takiej jak proces kasowania lub wyszukiwanie produktów). Każda funkcja będzie reprezentować Ograniczony kontekst. A każdy z nich zostanie podzielony przez dedykowany, Wielofunkcyjny zespół.
ponadto zespół powinien skupić się na swoim zadaniu, którym jest:
- wiernie replikować istniejącą funkcjonalność,
- lub (lepiej) zbudować zupełnie nowe, ulepszone doświadczenie dla swoich klientów.
w ramach procesu zespół powinien zaprojektować system, który najlepiej nadaje się do przedsięwzięcia.
na przykład, możemy zdecydować się na usunięcie funkcji wyszukiwania produktów z naszego monolitu. Zespół wyszukiwania produktów może ostatecznie zaprojektować system, który obejmuje:
- Kafka
- wydawca Kafki, który wprowadza zmiany w swoim SoR na wewnętrzny temat Kafki
- inny konsument Kafki, który słucha tego wewnętrznego tematu i aktualizuje Elastyczny indeks wyszukiwania
- punkt końcowy GraphQL do bezpłatnych wyszukiwań, który pyta o elastyczne wyszukiwanie
- punkt końcowy ReST, który pobiera poszczególne produkty za pomocą identyfikatora
- przeprojektowana aplikacja internetowa, która wykorzystuje te punkty końcowe, aby umożliwić klientom wyszukiwanie produktów i przeglądanie szczegółów produktu
- podobny zestaw ekranów w naszych aplikacjach mobilnych, które wykorzystują te punkty końcowe
- wydawca Kafki, który wypycha wiadomości, reprezentowanie różnych zapytań wykonywanych przez klientów, do zewnętrznego tematu Kafki, do wykorzystania przez dowolny inny Ograniczony kontekst (powiedzmy analitykę), który może być zainteresowany
gdy zaczynamy odrywać coraz więcej pionowych części naszego monolitu, inne zespoły budują własne konteksty ograniczone. Te ograniczone konteksty mogą wyglądać zupełnie inaczej.
zauważ, że komponenty w danym ograniczonym kontekście mogą być ściśle powiązane; jednak utrzymujemy nasze ograniczone konteksty oddzielone od siebie. W naszym przykładzie każda komunikacja między ograniczonymi kontekstami odbywa się poprzez przekazywanie wiadomości przez kolejkę komunikacyjną Kafki. Co ważne, unikamy synchronicznych wywołań żądań / odpowiedzi między ograniczonymi kontekstami.
dotyczy to również tego, co pozostało z monolitu. Z pewnością nie chcemy ścisłego powiązania naszych nowych mikroserwisów z naszym starym monolitem. Tak więc, gdy odrywamy części monolitu, wykorzystujemy przekazywanie wiadomości, aby pozostałe części mogły komunikować się z naszymi nowymi ograniczonymi kontekstami.
Reality check na temat tego odsprzęgania
w tym momencie możemy zadać sobie pytanie, czy naprawdę możliwe jest oddzielenie naszych ograniczonych kontekstów.
w prawdziwym świecie, czy naprawdę możemy chronić nasze zespoły przed zewnętrznymi zależnościami? Czy nigdy nie będzie przypadków, w których zespół musi zostać zablokowany przez inny zespół, aby wykonać swoją pracę?
i czy rzeczywiście możemy stworzyć architektury usług dla naszych subdomen, które są całkowicie oddzielone od innych subdomen? Czy naprawdę nie ma potrzeby, aby aplikacja w jednym ograniczonym kontekście kiedykolwiek synchronicznie wywoływała usługę w innym?
w rzeczywistości niemożliwe może być trzymanie naszych ograniczonych kontekstów w 100% odsprzęgniętych. Ale możemy się zbliżyć, znacznie bliżej, niż większość z nas może myśleć.
prawdziwe architektury
zacznijmy od spojrzenia na Architektury odsprzęgnięte. Często kupujemy błąd, że każdy rodzaj danych powinien mieszkać w dokładnie jednej lokalizacji, a każdy inny system musi bezpośrednio wywołać tę jedną lokalizację, aby uzyskać dostęp do danych.
odnosimy się do tego jako przypisania jednego źródła prawdy (SSoT) do naszych danych. Ale jak opisano w tym artykule, który analizuje ideę Ssot, to samo pojęcie jest w zasadzie anty-wzorcem. Zamiast tego większość ograniczonych kontekstów powinna przechowywać własną lokalną kopię wszelkich danych, których potrzebują do użycia.
jest to przykład naszego kontekstu związanego z wyszukiwaniem produktów z poprzedniej sekcji. Ten Ograniczony kontekst oczywiście zależy w dużej mierze od danych katalogów produktów naszej organizacji. Ale są szanse, że dane są generowane w innym ograniczonym kontekście(nazwiemy to kontekstem ograniczonym produktem).
naszym pierwszym (naiwnym) podejściem może być ujawnienie ReST API z kontekstu ograniczonego do wprowadzania produktów i zmuszenie usług w kontekście ograniczonego do wyszukiwania produktów do wywołania tego API. Ale stać nas na więcej. Zamiast tego możemy utrzymać systemy oddzielone od siebie, publikując zmiany wprowadzone przez usługi wprowadzania produktów na Kafce. Nasz produkt-search klienci Kafka następnie odebrać te wiadomości i zaktualizować baz danych produktów-Search.
zauważ, że te dwa ograniczone konteksty są ostatecznie spójne. Oznacza to, że istnieją krótkie okresy, w których dane mogą być niespójne między wprowadzaniem produktu a wyszukiwaniem produktu. Na przykład, jeśli cena białych widżetów Wombat zostanie podniesiona z $1.99 do $2.49, będzie krótki okres czasu (często kwestia sekund, jeśli nie milisekund), w którym istnieje różnica w cenie białego widgetu Wombat w dwóch ograniczonych kontekstach.
prowadzi to do rzeczywistych przypadków, w których nie mamy alternatywy, jak tylko konteksty ograniczone parami. W niektórych przypadkach ewentualna spójność jest niedopuszczalna. Na przykład, zanim klient będzie mógł dokonać zakupu online, Być może będziemy musieli upewnić się, że każdy produkt w jego koszyku jest w rzeczywistości dostępny w tym momencie. Nawet wtedy często możemy zminimalizować sprzężenie między dwoma ograniczonymi kontekstami.
nasze interakcje mogą wyglądać tak:
- ponieważ klient używa interfejsu wyszukiwania produktów do wyszukiwania produktów, bazy danych wyszukiwania produktów są używane do pobierania informacji (takich jak style, recenzje klientów, ceny itp.) o produktach
- nawet gdy klient rozpoczyna proces realizacji zamówienia, nadal korzystamy z baz danych wyszukiwania produktów, aby uzyskać informacje, które muszą zostać wyświetlone.
- wreszcie, gdy klient kliknie ten ostateczny przycisk „kompletny zakup”, wykonujemy jedno, synchroniczne wywołanie kontekstu ograniczonego wpisem produktu, aby sprawdzić dostępność produktów przed zakończeniem zakupu.
kolejny powszechny przykład, który wymaga natychmiastowej spójności związanej z autoryzacją. W wielu systemach tokeny bezpieczeństwa muszą być pobierane lub weryfikowane na każde żądanie. W takich przypadkach prawdopodobnie musimy pozwolić naszym ograniczonym kontekstom nazywać inny, zorientowany na bezpieczeństwo kontekst Ograniczony.
prawdziwe struktury org
a może samodzielne, wielopoziomowe zespoły? Jak to możliwe w prawdziwym świecie?
w rzeczywistości jest to proces ciągłego ruchu w kierunku całkowicie samodzielnych zespołów. Rzadko kiedy osiągniemy 100% autonomii z naszymi zespołami. Ale jeśli zaczniemy od inteligentnej organizacji naszych zespołów i rozpoznamy pojawiające się wąskie gardła i zareagujemy na nie, możemy się zbliżyć.
na początek, powinniśmy zmaksymalizować nasze zespoły pionowe, cross-funkcjonalne i zminimalizować liczbę zespołów poziomych, jednofunkcyjnych. Oznacza to opieranie się potrzebie tworzenia tak zwanych „podstawowych” zespołów – których misją jest budowanie wspólnych usług danych, które są wykorzystywane przez inne zespoły zorientowane na produkty-i zamiast tego formowanie naszych zespołów wokół wartości biznesowej, którą zapewnią.
wiele organizacji dąży do tego celu, najpierw tworząc zespoły zorientowane na domenę, składające się z menedżerów produktu oraz inżynierów front-end I back-end. To jakiś początek. Ale do kogo jeszcze powinny należeć te zespoły? Dokładne członkostwo może się różnić w różnych zespołach o różnych potrzebach. Ale powinniśmy rozważyć takie rzeczy jak:
- Jeśli nasz zespół ma inżynierów front-end, to prawdopodobnie powinni ściśle współpracować z grafikiem, który jest dedykowany tej domenie.
- Inżynierowie mobilni — często umieszczani we własnym obszarze organizacji — powinni być włączani do domen z komponentem mobilnym.
- w swoim pouczającym artykule o siatkach danych, Zhamak Dehghani ubolewa, że inżynierowie danych są często wykluczani z zespołów międzyfunkcyjnych-ze szkodą dla inżynierów danych i samych zespołów międzyfunkcyjnych.
Kiedy już ustalimy skład naszych zespołów, powinniśmy uważać na wąskie gardła. Czy są jakieś inne zespoły, które zwykle blokują produktywność naszych zespołów międzyfunkcyjnych?
na przykład wiele organizacji ma dedykowany zespół ds. bezpieczeństwa. Jest to oczywiście dobra praktyka; organizacje potrzebują spójnej strategii bezpieczeństwa i sposobu na zapewnienie nadzoru nad tą strategią. Jednak często zdarza się, że zespoły wstrzymują pracę na różnych etapach, aby umożliwić przeglądy bezpieczeństwa ich pracy. Nawet w najlepszych sytuacjach stwarza to przeszkody dla naszych zespołów jako rutynową praktykę biznesową. Co więcej, często będzie to prowadzić do tego, że zespoły będą musiały zrezygnować z całości lub części swojej pracy i zacząć od nowa, ponieważ odkryją wymagania bezpieczeństwa, które nie zostały spełnione.
to wyraźnie nieprzyjemny zapach. Ale jak możemy egzekwować standardy bezpieczeństwa naszej organizacji, jednocześnie pozwalając zespołom zachować autonomię i produktywność?
możemy to zrobić, dodając inżynierów bezpieczeństwa do naszych zespołów funkcjonalnych. Możemy zastosować trzy podejścia:
- Jeśli mamy szczęście mieć stosunkowo duży zespół ds. bezpieczeństwa, możemy przydzielić każdemu zespołowi funkcjonalnemu pełnoetatowego inżyniera ds. bezpieczeństwa (SE).
- w przypadku mniejszych zespołów bezpieczeństwa, każdy SE może być przypisany do wielu zespołów funkcjonalnych w niepełnym wymiarze godzin. Pozwoli to SEs zrozumieć cele i projekty zespołów oraz współpracować z zespołem w celu przestrzegania standardów bezpieczeństwa organizacji w całym procesie.
- Jeśli nie mamy wystarczająco dużo zasobów bezpieczeństwa dla obu możemy iść w przeciwnym kierunku. Zamiast przyprowadzać członków zespołu ds. bezpieczeństwa do naszych zespołów międzyfunkcyjnych, możemy zaprosić członków zespołów międzyfunkcyjnych do zespołu ds. bezpieczeństwa. Każdy międzyfunkcyjny zespół wyznaczył jednego lub dwóch przedstawicieli ochrony. Przedstawiciele będą okresowo spotykać się z bezpieczeństwem i być na bieżąco z wymaganiami i standardami bezpieczeństwa organizacji. Sami mogą nie być ekspertami od bezpieczeństwa. Będą jednak w stanie pełnić rolę inżyniera ds. bezpieczeństwa, zapewniając, że ich zespoły będą stosować się do praktyk bezpieczeństwa organizacji.
Gildie
to wpisuje się w inny schemat organizacyjny, który zyskuje na popularności: Gildie. Model Gildii narodził się z modelu zespołu cross-functional. Ze względu na swoją naturę zespoły te są zamieszkane przez członków, którzy specjalizują się w różnych funkcjach. Jednak często ma to sens dla ludzi, którzy specjalizują się w określonej funkcji, aby spotkać się razem, jak również; na przykład, aby:
- doskonal swoje umiejętności i ucz się od siebie nawzajem
- Odkryj i ustal najlepsze praktyki dla ich konkretnej funkcji
- w zależności od funkcji stwórz standardy i wymagania firmy
nasze ostatnie rozwiązanie bezpieczeństwa skutecznie utworzyło „gildię bezpieczeństwa”. Członkowie zespołu pracowali głównie ze swoimi pionowymi zespołami; ale okresowo niektórzy z nich spotykali się z „gildią” bezpieczeństwa, aby omówić praktyki i standardy bezpieczeństwa organizacji.
model Gildii działa również szczególnie dobrze, jeśli chodzi o architekturę oprogramowania. Szczególnie w przypadku architektury mikroserwisów wymagany jest pewien poziom zarządzania technicznego w całej organizacji. Jednak grupa architektów siedzących w metaforycznej wieży z Kości Słoniowej, rozdających Zasady zespołom, jest na ogół przeciwna do zamierzonego. Zamiast tego, starsi / główni inżynierowie z naszych międzyfunkcyjnych zespołów mogą okresowo spotykać się w gildii architektów. Tam mogą podnosić problemy ze swoimi zespołami, opracowywać rozwiązania i ustanawiać patenty i standardy.
gildie mogą być również rozszerzone na prawie wszystkie inne funkcje. W końcu chcemy, aby projektanci opracowywali i pracowali na podstawie wspólnego przewodnika po stylu interfejsu użytkownika. Chcemy, aby nasi inżynierowie frontend używali tych samych elementów interfejsu użytkownika. Inżynierowie ds. kontroli jakości powinni być dostosowani do sposobu przeprowadzania testów w naszych organizacjach. Menedżerowie produktu powinni być zsynchronizowani z ogólną mapą produktową organizacji.
Połącz to wszystko
przejście na mikroserwisy może znacznie poprawić produktywność naszych zespołów. Ale musimy zrozumieć, jak wykorzystać architekturę mikroserwisów, aby się tam dostać. Ze wszystkich wzorców projektowych i koncepcji, które odnoszą się do mikroserwisów, Ograniczony kontekst jest prawdopodobnie najważniejszym, który daje nam to zrozumienie.
z solidnym zrozumieniem ograniczonego kontekstu rozumiemy, że:
- nasza struktura organizacyjna i nasza Architektura techniczna idą w parze
- nasze zespoły zorientowane na produkty powinny mieć minimalne zależności od innych zespołów, tak jak systemy, które budują, powinny być oddzielone od innych systemów
ogólnie rzecz biorąc, uwzględnienie ograniczonego kontekstu daje myśl, że musimy odnieść sukces z naszą architekturą mikroserwisów. Upewnij się, że rozumiesz ten ważny wzór, zanim wyruszysz w podróż po mikroserwisach!
