Archyno
UMLPrax modelovania

Architektúra e-shopu, namodelovaná

Jeden internetový obchod, nakreslený trikrát: doména, s ktorou pracuje, služby, z ktorých je postavený, a stroje, na ktorých beží. Tri diagramy, tri rôzne otázky a na žiadnom nič, čo patrí na iný.

9 min čítaniaUML 2.5.132 z 35

Krátka odpoveď

  • Tri diagramy pokryjú takmer každý rozhovor: diagram tried na doménu, diagram komponentov na zmluvy, diagram nasadenia na stroje.
  • Kreslite zmluvu, nie dodávateľa. Rozhranie IPayment s adaptérom pre Stripe hovorí, že obchod závisí od schopnosti a nie od značky.
  • Či je košík samostatnou službou, je rozhodnutie, nie fakt. Košík, ktorý prežije prechod medzi zariadeniami, je stav, ktorý niekto vlastní, a dostane zmluvu.
  • Databáza je uzol na diagrame nasadenia a adaptér na diagrame komponentov. Nikdy ten istý box na oboch.
UML diagram komponentov e-shopového systému. Storefront aj Admin console závisia od rozhrania IOrders, ktoré realizuje Order service. Order service závisí od rozhrania IPayment, ktoré realizuje adaptér platobnej brány, a od rozhrania IStock, ktoré realizuje Inventory service.
Pohľad, ktorý väčšina ľudí myslí slovom "architektúra": štyri služby, tri kontrakty a jeden adaptér stojaci medzi obchodom a poskytovateľom platieb, od ktorého obchod nezávisí menom.

01Tri diagramy, tri otázky#

Obchod je príklad, po ktorom siahne každý, a dôvod, prečo je väčšina diagramov obchodu zbytočná, je ten, že sa snažia byť jedným obrázkom. Slovník, hranice služieb a stroje sú tri rozdielne témy a kresba, ktorá ich mieša, neodpovie ani na jednu - je to ten diagram s triedou Order, logom Kubernetes a frontou na jednom plátne.

Rozdeľte podľa otázky a každá sa dá overiť:

  1. Aké sú podstatné mená? Diagram tried domény. Čím je objednávka, z čoho sa skladá, bez čoho nesmie existovať.
  2. Kto smie koho volať? Diagram komponentov služieb a kontraktov medzi nimi.
  3. Kde to beží? Diagram nasadenia uzlov a artefaktov na nich.

Nič z toho nie je diagram front, sekvenčný diagram ani výpis infraštruktúry ako kódu, a je to zámerné. Tie existujú a sú užitočné; sú tiež miestom, kde dokumentačná sada zomrie, ak prvé tri nie sú v poriadku.

021. Doména#

UML diagram tried e-shopovej domény. Customer zadáva nula alebo viac Order. Order je zložená z jednej alebo viacerých OrderLine a je v asociácii s jedným Payment. Každá OrderLine odkazuje na jeden Product. Payment je v asociácii s jedným Shipment.
Päť tried a štyri vzťahy. Plný kosoštvorec je celé to tvrdenie: OrderLine nemôže existovať bez svojej Order a zomrie s ňou, kým Product objednávku, ktorá naň odkazovala, zjavne prežije.

Toto je diagram, ktorý usadí slovník, a slovník je miesto, kde sa obchody pokazia najskôr. Je "košík" objednávka, ktorá nebola zadaná, alebo iná vec? Drží OrderLine cenu v čase nákupu, alebo ju číta z Product? Druhá otázka je na obrázku zodpovedaná - unitPrice žije na položke - a práve ten jediný atribút je rozdielom medzi obchodom, ktorého staré faktúry zostanú po zmene cien správne, a obchodom, ktorého nie.

032. Služby#

Obrázok v hlavičke tohto článku. Dvaja klienti, jedna objednávková služba a dva kontrakty, od ktorých závisí - sklad a platby. Čítajte ho zakrývaním boxov: zakryte objednávkovú službu a zostane IOrders, IStock a IPayment, čo je presne tá špecifikácia, ktorú by musela naplniť náhrada.

Adaptér je ten kus, ktorý sa oplatí okopírovať. IPaymentje kontrakt, ktorý vlastní obchod; realizuje ho adaptér Stripe. Nič v objednávkovej službe nepomenúva poskytovateľa, takže "čo by stál prechod na Adyen?" má odpoveď, na ktorú vidíte - jeden box a čokoľvek, čo sa ukáže, že adaptér prepustil. Nakreslené naopak, s objednávkovou službou závislou priamo od komponentu Stripe, potrebuje tá istá otázka hľadanie v kóde.

Čo zámerne chýba: košík, vyhľadávací index, odporúčací engine, odosielač e-mailov. Každé z nich je skutočné a ani jedno nemení odpoveď na otázku "kto smie koho volať na ceste pokladne". Idú na vlastný diagram, keď na ne niekto bude mať otázku.

043. Nasadenie#

UML diagram nasadenia e-shopového systému. Zariadenie s prehliadačom komunikuje cez HTTPS s CDN a edge prostredím, ktoré komunikuje s klastrom Kubernetes obsahujúcim artefakty storefrontu a objednávkovej služby. Klaster sa cez TCP 5432 dostane na zariadenie PostgreSQL a cez HTTPS na Stripe API.
Kde to beží, a jediný z tých troch diagramov, ktorý sa zmení pri prechode na inú platformu. Artefakty sedia vnútri uzla, ktorý ich vykonáva; označené cesty nesú protokol a port.

Toto je diagram, ktorý nikto nekreslí až do prvého incidentu, a ten, ktorý odpovedá na otázky, na ktoré tie druhé dva nevedia: čo je dosiahnuteľné z internetu, čo hovorí s databázou a kde sedí hranica k tretej strane. Stripe API je nakreslené ako externý uzol práve preto, že nie je vaše - ten box je pripomienkou, že jeho dostupnosť je závislosťou, ktorú neriadite.

Je to zároveň jediný z tých troch, ktorý zastará v obyčajný utorok. Doménový model prežije prechod na inú platformu nedotknutý a pohľad na komponenty tiež; diagram nasadenia zneplatní migrácia klastra. Tá asymetria je dobrým dôvodom držať ho oddelene namiesto zabalenia "beží na Kubernetes" do boxov komponentov.

Po jednom riadku na každé

  1. 01Tri diagramy, tri otázky: podstatné mená, kontrakty, stroje.
  2. 02Kompozícia oproti asociácii na Order, OrderLine a Product je celým nákladom doménového modelu.
  3. 03Vlastnite platobný kontrakt a nechajte poskytovateľa pomenovať adaptér - práve to robí prechod ocenitelným.
  4. 04Zakryte ktorýkoľvek komponent: to, čo zostane, musí špecifikovať jeho náhradu.
  5. 05Vyhľadávanie, e-maily a odporúčania nechajte mimo diagramu pokladne; odpovedajú na inú otázku.
  6. 06Zastará len pohľad na nasadenie, a preto je to vlastný obrázok.

Notácia za prostredným diagramom, s piatimi ďalšími topológiami, je v príkladoch diagramov komponentov. Na vytvorenie prvého návrhu ktoréhokoľvek z tých troch z popisu namiesto ručného kreslenia pozrite generovanie UML pomocou AI.

05Časté otázky#

Aké diagramy potrebujem na zdokumentovanie e-shopu?

Tri pokryjú takmer každý rozhovor: diagram tried na doménový slovník, diagram komponentov na to, ktorá služba smie volať ktorú zmluvu, a diagram nasadenia na to, kde všetko beží. Sekvenčný diagram pridajte len na jeden či dva naozaj sporné toky, zvyčajne pokladňu a vratky.

Ako namodelovať platobnú bránu bez naviazania diagramu na jedného dodávateľa?

Kreslite zmluvu, nie dodávateľa. Rozhranie IPayment s adaptérom pre Stripe, ktorý ho realizuje, hovorí, že obchod závisí od schopnosti a nie od značky - čo je pravdivejšie a zároveň to, čo chcete vedieť overiť, keď niekto navrhne zmenu poskytovateľa.

Má byť nákupný košík samostatnou službou?

Na diagrame je to rozhodnutie, nie fakt, takže ho nakreslite tak, ako váš systém naozaj funguje. Košík žijúci vo frontende je záležitosťou klienta a nepotrebuje box; košík, ktorý prežije prechod medzi zariadeniami, je stav, ktorý niekto vlastní, a dostane komponent so zmluvou ako čokoľvek iné.

Kam patrí databáza na diagrame architektúry?

Na diagram nasadenia ako uzol a na diagram komponentov len ako adaptér pred ňou. Toto rozdelenie drží pohľad na komponenty pri zmluvách, od ktorých závisí váš kód, a otázku, ktorá verzia Postgresu kde beží, necháva jedinému diagramu, ktorý je o strojoch.

V tejto sérii

Súvisiace články

Všetky články