Diagramy návrhu architektury

Architekti často komunikují prostřednictvím diagramů. Dobře navržené vizuály jsou výkonné nástroje, které pomáhají implementátorům, kontrolorům zabezpečení a obchodním stakeholderům konvergovat na sdíleném mentálním modelu, odhalit rizika dříve a snížit přepracování. Aby architekt chtěl komunikovat se záměrem, musí vybrat a často vrstvit typy diagramů, které odpovídají fázi zprávy, cílové skupiny a životního cyklu.

Volba diagramu architektury nakonec závisí na tom, co se snažíte sdělit, a na otázkách, které má vaše cílová skupina. Architekti používají více typů diagramů v rámci aktivit návrhu, upřesnění požadavků a komunikace účastníků. Očekávejte, že budete udržovat více diagramů v rámci představy, rozpracování návrhu, modelování hrozeb, implementace, provozu a řízení.

Postupy vytváření diagramů

Efektivní diagramy sdělují podstatné informace bez nutnosti rozsáhlého textového vysvětlení. Pokud se chcete vyhnout nejednoznačnosti a zajistit jasnou komunikaci, postupujte podle těchto doporučení:

Používejte standardní notace. Používejte široce rozpoznané symboly, ikony a konvence prezentací, abyste zajistili dobrou čitelnost a konzistentní interpretaci napříč různými cílovými skupinami.

Vyhněte se nejednoznačným řádkům. Diagramy často zobrazují vztahy mezi entitami pomocí čar. Buďte konzistentní v tom, jak tyto vztahy reprezentujete v diagramech.

Použijte směrové šipky. Čáry bez šipek činí vztahy nejasnými. Vždy používejte šipky a pokud existuje obousměrná komunikace, buď zobrazte dva samostatné toky (upřednostňované), nebo označte jednu šipku poznámkami s poznámkami k žádosti a odpovědi.

Vyhněte se obousměrným šipkám. Dvojité šipky znamenají obousměrné závislosti, které můžou způsobit nejasnosti. Pomocí šipek s jedním koncem můžete znázorňovat tok z iniciační komponenty (klienta) na závislost (server).

Označit vše jasně. Zadejte jasné, přesné a smysluplné popisky pro každou ikonu, kontejner seskupení a relaci. Popište čáry, pokud relace nejsou okamžitě zřejmé z kontextu.

Udržujte konzistenci. Pro podobné prvky používejte standardizované barvy, ikony, velikosti ikon, tloušťky čar, typy čar, šipkové hlavy a styly ohraničení. Použijte stejnou taxonomii v každém diagramu v sadě řešení. Čerpejte z existujících organizačních standardů nebo taxonomií.

Buďte přesní. I když jsou diagramy abstrakce, neubíjejte přesnost kvůli zbytečné jednoduchosti. Například nezobrazujte službu PaaS uvnitř podsítě, pokud k ní skutečně přistupujete přes privátní koncový bod. Nepřesnosti v diagramech mohou vést k vážným nedorozuměním a zpožděním nebo chybám při implementaci. Vyřaďte diagramy, které již přesně neodpovídají na aktivní otázky zúčastněných osob.

Zahrnout metadata. Ujistěte se, že každý diagram obsahuje metadata, která poskytují základní kontext pro jeho účel, rozsah a významnost. Uveďte prvky, jako je název, popis, datum poslední aktualizace, autor, verze a externí odkazy. Tyto informace pomáhají divákům pochopit záměr diagramu a aktuálnost. Po širokém sdílení diagramu pomáhá udržet propojený protokol změn vracejícím se čtenářům vědět, co se změnilo.

Používejte oficiální ikony a názvy služeb. Při reprezentaci konkrétních technologií vždy používejte nejnovější oficiální ikony a zásady vytváření názvů. Nepřetahujte ani nepřebarvujte obrazce značky libovolně. Nenahrazujte koncepční prvky, například obecné bloky brány rozhraní API, marketingovými logy, jako jsou loga dodavatelů.

Tady jsou například ikony pro služby Microsoftu:

Zadejte legendu. Pokud například zavádíte sémantiku ohraničení nebo čáry, kde "solid" znamená synchronní volání a "dash" znamená asynchronní volání, uveďte kompaktní legendu.

Návrh pro usnadnění přístupu Zajistěte dostatečný barevný kontrast. Vyhněte se spoléhat výhradně na barvu k rozlišení typů, místo toho konzistentně spárujte barvu se vzorem.

Nepřetěžujte vrstvy. Rezistujte nutkáním kódovat každý subsystém, klasifikaci dat a cestu modulu runtime v jednom diagramu. Zajištění progresivního zpřístupnění: kontextový diagram vede k diagramu kontejneru, který vede k prioritní komponentě nebo sekvenčnímu diagramu pro kritický případ použití.

Správa verzí Ukládejte zdrojové soubory diagramu ve stejném úložišti nebo úložišti dokumentace jako ostatní prostředky verze úlohy.

Typy diagramů návrhu

Architektura úloh je složitá a multidimenzionální. Různé typy diagramů se zaměřují na konkrétní aspekty systému a poskytují cílové úrovně podrobností pro každou dimenzi. Vývojové diagramy například znázorňují tok procesu, zatímco diagramy vztahů mezi entitami zobrazují vztahy mezi systémovými komponentami.

Použití různých typů diagramů umožňuje komplexní porozumění všem dimenzím architektury. Tento přístup usnadňuje efektivní komunikaci, řešení problémů a rozhodování mezi různými zúčastněnými stranami s různými technickými pozadími a obavami. Vaše záznamy rozhodnutí o architektuře slouží jako reference k těmto diagramům pro vizualizaci rozhodnutí.

Následující typy zahrnují běžné artefakty komunikace cloudové architektury a několik doplňků s vysokou hodnotou. Seznam typů diagramů není vyčerpávající. V praxi je mnoho artefaktů hybridní nebo se vyvíjí. Pokud chcete vizualizovat úlohu, upřednostněte minimální sadu účelových diagramů před vytvořením každého možného typu. Začněte široce, postupně zúžit a pak použijte scénář a průřezové pohledy.

Kontextový diagram

Kontextový diagram představuje úlohu jako jediný černý rámeček v jeho externím prostředí. Pojmenuje systém, stručně uvádí svůj účel a zobrazuje externí osoby, nadřazené a podřízené systémy a zdroje dat nebo jímky, které s ním komunikují. Zobrazí se pouze komunikační nebo integrační cesty vysoké úrovně; interní struktura je záměrně vynechána, takže cílová skupina se zaměřuje na hranice rozsahu a závislosti, nikoli na implementaci. Spoléhat se na obecné tvary externích systémů místo loga produktů a vždy zahrnout explicitní hranici, aby čtenáři nemuseli odvozovat rozsah.

Diagram systému nebo kontejneru vysoké úrovně

Diagram systému vysoké úrovně poskytuje široký přehled o celé úloze nebo hlavní pododdílu v rámci úlohy. Rozdělí úlohu do svých hlavních komponent, jejich vztahů a obecného toku dat prostřednictvím systému. Šipky označují směr interakcí a závislostí.

Tento diagram použijte po zarovnání kontextu k odhalení makrostruktury, hostitelských modelů, jako jsou PaaS nebo samospravované, a externích závislostí. Tyto diagramy jsou vynikající pro vytvoření společného porozumění zúčastněným stranám před tím, než se ponoří do hlubších technických diskuzí. Jsou také cenné pro komunikaci s vedoucími pracovníky a zúčastněnými stranami, kde je důležité spíše vysoká úroveň porozumění než technické podrobnosti.

Blokový nebo funkční diagram

Blokový diagram rozdělí úlohu do hlavní funkční schopnosti pomocí technologicky neutrálních bloků, které se zaměřují na funkčnost, která je prováděná, a ne na konkrétní komponentu.

Například blokový diagram může odkazovat na frontu objednávek nebo sběrnici zasílání zpráv místo zadávání konkrétní technologie sběrnice zpráv, jako je Azure Service Bus nebo Apache Kafka. Tato úroveň abstrakce pomáhá vysvětlit strukturu systému, tok dat a tok zpracování bez zahlcení cílové skupiny specifiky implementace, což je ideální pro diskuze o počátečních modelech domény a shromažďování požadavků.

Diagram komponent

Diagram komponent vychází z blokových diagramů nahrazením obecných funkčních bloků konkrétními technologiemi a integračními body. Představuje podrobné zobrazení, které komunikuje s konkrétní technologií systému a jejich vztahy, jako jsou interakce mezi klientem a serverem. Tyto diagramy slouží jako vizuální faktura materiálů pro architekturu, která ukazuje, které technologie budou implementovány.

Diagram nasazení

Diagram nasazení se zaměřuje na to, jak se infrastruktura, komerční software (COTS) a vlastní kód nasadí v hostitelském prostředí. Zobrazuje mapování mezi softwarovými komponentami a fyzickou nebo virtuální infrastrukturou, která je hostuje.

Tyto diagramy jsou užitečné pro plánování DevOps, nastavení prostředí a pochopení provozních aspektů architektury. Pomáhají týmům vizualizovat hranice škálování, jednotky nasazování, závislosti infrastruktury a prostředí.

Diagram toku dat (DFD)

Diagram toku dat (DFD) znázorňuje, jak se data přesouvají, transformují, ukládají a vystupují ze systému. Zvýrazněte zdroje, jímky, fáze transformace, klasifikaci (veřejné, důvěrné, regulované) a to, jestli je přesun dávkový, streamovaný nebo téměř v reálném čase. Pomáhá s analýzou rodokmenu dat, kontrolami zásad správného řízení a identifikací kritických bodů výkonu.

Modelování hrozeb zabezpečení, jako je model STRIDE, používá specializované DFD. Diagram znázorňuje procesy, úložiště dat, externí entity, hranice důvěryhodnosti a toky dat překračující tyto hranice. Zaměřuje se na přidávání poznámek k tokům pomocí protokolů a šifrování a zvýrazňuje prostředky vyžadující ochranu. Tento obrázek řídí identifikaci zmírnění rizik a ověřování kontrolních mechanismů zabezpečení.

Sekvenční diagram

Sekvenční diagram znázorňuje dočasné řazení interakcí pro jeden případ použití nebo scénář. Například uživatel umístí objednávku. Znázorňuje vztahy mezi klientem a serverem a jasně ukazuje, jestli jsou interakce synchronní nebo asynchronní. Tyto diagramy také zvýrazňují závislosti v komunikačních vzorech a pomáhají vyhodnotit potenciální scénáře selhání v rámci interakcí komponent. Sekvence diagramů jsou zvláště cenné pro návrh rozhraní API.

Diagram toku uživatele nebo cesty

Diagram toku uživatele znázorňuje kompletní kroky, které uživatel nebo persona provádí napříč rozhraními a službami. Vizualizuje cestu uživatele systémem a ukazuje, jak uživatelé a jejich data pracují s různými komponentami a procesy. Tyto diagramy jsou užitečné pro objasnění funkčních požadavků, ověřování návrhu uživatelského prostředí a zajištění správného řešení všech uživatelských scénářů v architektuře. Poznámkami týkajícími se výkonu nebo očekávání na úrovni služeb u kritických toků

Diagram vztahů entit (ERD)

Diagram relací entit (ERD) představuje logickou nebo fyzickou strukturu datového modelu: entity (tabulky a kolekce), atributy, klíče a kardinality. Použijte logické ERD pro zarovnání domény a fyzické ERD pro podrobnosti implementace (indexy, dělení). Někdy lze v tomto diagramu sdělit podrobnosti, jako jsou rozsahy horizontálního dělení. Tyto diagramy pomáhají vývojářům porozumět vztahům a omezením dat před zahájením implementace.

Diagram připojení k síti

Síťový diagram znázorňuje úlohy z pohledu síťové infrastruktury a ukazuje, kde komponenty komunikují přes hranice sítě. Tyto diagramy vizualizují segmentaci sítě, potenciální body selhání sítě a kritické síťové přechody, jako jsou příchozí a výstupní body internetu. Úloha může mít prospěch z jednoho síťového diagramu, který se zaměřuje na provoz na východ-západ a další síťový diagram pro provoz na sever-jih.

Síťové diagramy často mají rozšířený nástroj nad rámec počáteční fáze implementace. Často se na ně odkazuje při auditech zabezpečení, kontrolách dodržování předpisů a aktivitách reakce na incidenty, což z nich dělá cenné dlouhodobé prostředky dokumentace.

Stavový diagram

Stavový diagram je specializovaná vizualizace, která znázorňuje možné stavy objektu domény, pracovního postupu nebo subsystému. Zahrnuje podmínky nebo události, které aktivují přechody mezi stavy. Například popis, jak postupuje objednávka od konceptu, k odeslání, ke kontrole, ke splnění, až po uzavření.

Stavové diagramy pomáhají zvýraznit potenciální problémy souběžnosti, zpracování přechodu a kompenzační potřeby transakcí. Pomáhá to snížit pravděpodobnost neočekávaných změn stavu v produkčním prostředí.

Diagram aktivit a vývojový diagram

Vývojové diagramy a diagramy aktivit přinášejí přehlednost složitých pracovních postupů, rozhodovací logiky a obchodních procesů v rámci vaší úlohy. Jsou užitečné pro reprezentaci schvalovacích procesů a scénářů podmíněného větvení, které vám pomůžou zdokumentovat provozní runbooky, automatizaci obchodních procesů a toky reakcí na incidenty.

Další specializované diagramy

Typ Když přidá jedinečnou hodnotu Fokus
Mapa dostupnosti a odolnosti Během kontrol plánování zotavení po havárii a cíle úrovně služeb (SLO) Zobrazit redundanci, cesty selhání, poznámky RPO/RTO.
Mapa rezidence dat dodržování předpisů Regulované úlohy Umožňuje zobrazit umístění dat, replikaci, klasifikaci, uchovávání informací.
Diagram toku identit a přístupu Kontroly zabezpečení a dodržování předpisů Zobrazení toků ověřování a autorizace Určete, kde dochází k vystavování tokenů, kde se mění hranice důvěryhodnosti a kde dochází k tokům jménem.

Diagramy založené na specifikaci

Existuje několik otevřených specifikací, na které můžete založit diagramy. Přijetí jednoho je záležitostí rozhodnutí celého týmu; mělo by k němu dojít pouze tehdy, pokud přidá potřebnou sdílenou slovní zásobu ke snížení nejednoznačnosti. Pokud váš aktuální vizuální komunikační přístup už funguje, vyhněte se přidávání váhy procesů jen pro formální účely. I když specifikaci nepřijmete, selektivní výpůjčky prověřených konvencí (vrstvení, zápis kardinality, popisky událostí, vzory legendy) můžou zvýšit srozumitelnost a konzistenci v celé sadě diagramů.

Příklady specifikací diagramů a modelování:

Další kroky

Kontrolní seznam architekta

  • Last updated on