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.
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ť:
- Aké sú podstatné mená? Diagram tried domény. Čím je objednávka, z čoho sa skladá, bez čoho nesmie existovať.
- Kto smie koho volať? Diagram komponentov služieb a kontraktov medzi nimi.
- 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#
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#
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é
- 01Tri diagramy, tri otázky: podstatné mená, kontrakty, stroje.
- 02Kompozícia oproti asociácii na Order, OrderLine a Product je celým nákladom doménového modelu.
- 03Vlastnite platobný kontrakt a nechajte poskytovateľa pomenovať adaptér - práve to robí prechod ocenitelným.
- 04Zakryte ktorýkoľvek komponent: to, čo zostane, musí špecifikovať jeho náhradu.
- 05Vyhľadávanie, e-maily a odporúčania nechajte mimo diagramu pokladne; odpovedajú na inú otázku.
- 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
- 01Čo je UML?
- 02Symboly UML
- 03Výber diagramu
- 04Diagramy tried
- 05Príklady diagramov tried
- 06Ako nakresliť diagram tried
- 07Symboly diagramu tried
- 08Sekvenčné diagramy
- 09Príklady sekvenčných diagramov
- 10Ako nakresliť sekvenčný diagram
- 11Diagramy prípadov použitia
- 12Príklady prípadov použitia
- 13Diagramy aktivít
- 14Príklady aktivít
- 15Stavové diagramy
- 16Príklady stavových diagramov
- 17Diagramy komponentov
- 18Príklady komponentov
- 19Kreslenie diagramu komponentov
- 20Symboly komponentov
- 21Diagramy nasadenia
- 22Príklady nasadenia
- 23Diagramy objektov
- 24Diagramy balíkov
- 25Diagramy zloženej štruktúry
- 26Komunikačné diagramy
- 27Sekvenčný vs komunikačný
- 28Časové diagramy
- 29Diagramy prehľadu interakcií
- 30Diagramy profilov
- 31UML pomocou AI
- 32Príklad e-shopu
- 33Príklad banky
- 34Príklad mikroslužieb
- 35Príklad AWS
Súvisiace články
Diagramy štruktúry
Diagramy štruktúry
Diagramy štruktúry
Diagramy štruktúry
Prax modelovania
Prax modelovania