Ako nakresliť diagram komponentov

Skôr než čokoľvek nakreslíte, spíšte zoznam. Nie svojich modulov, nie svojich priečinkov - častí systému, ktoré by sa reálne dali vymeniť za inú implementáciu: kúpené namiesto postavené, prepísané iným tímom alebo prevádzkované niekým iným.

Práve táto otázka je celý filter. Priečinok nie je komponent a trieda tiež nie; vec s hranicou, ktorú by ste vedeli odovzdať dodávateľovi, áno. Reportovací systém v tomto článku ich dal štyri: dashboard, plánovač, ktorý spúšťa reporty cez noc, samotnú službu reportov a adaptér, ktorý hovorí s dátovým skladom.

Umiestnite časti a odolajte pokušeniu spojiť ich. Kresliť šípky teraz znamená kresliť ich medzi komponentmi a čiara z Dashboardu rovno do Služby reportov hovorí len „tieto dva sú nejako zapojené“, čo je práve tá vágnosť, ktorú diagram komponentov existuje odstrániť.

Rozloženie tu stojí za tridsať sekúnd: dajte spotrebiteľov na jednu stranu a poskytovateľov na druhú. Každý diagram v tejto sérii je kreslený zľava doprava, so závislosťami tečúcimi jedným smerom, lebo potom čitateľ overí smer pohľadom namiesto sledovania každej čiary.

Pri každom boxe sa spýtajte, na čo sa smie spoľahnúť niekto zvonka, a to pomenujte. Tu IReports a IWarehouse - jedna zmluva na schopnosť, nie jedna na spotrebiteľa. Pripojte ju realizáciou: prerušovaná čiara, prázdny trojuholník, mieriaci na rozhranie.

Práve v tomto kroku sa deje skutočný návrh a práve tento krok ľudia preskakujú. Pomenovanie zmluvy vás núti rozhodnúť, čo je verejné, a hádka, ktorá nasleduje - „patrí export do CSV do IReports, alebo nie?“ - je hádka, ktorú sa oplatí zviesť skôr, než na ňu dva tímy odpovedia v kóde rozdielne.

Teraz druhá polovica a tá, ktorá nesie informáciu: ktoré zmluvy každý komponent potrebuje? Nakreslite závislosť - prerušovaná čiara, otvorený hrot - z komponentu na rozhranie, ktoré vyžaduje. Výsledok je diagram na začiatku článku.

Vo chvíli, keď tie šípky dopadnú, sa zviditeľnia dve veci. Dashboard aj plánovač mieria na IReports, takže jeho zmena je teraz viditeľne zmenou pre dvoch spotrebiteľov. A služba reportov mieri na IWarehouse, nie na adaptér, takže adaptér sa dá vymeniť bez toho, aby si to služba všimla - čo je buď to, čo ste zamýšľali, alebo objav, ktorý stojí za to urobiť teraz.

Diagram komponentov je hotový, keď ich prežije. Zaberú minútu a každá z nich odhalila skutočný problém častejšie, než prešla načisto.

1. Zakryte box dlaňou. To, čo zostane - rozhrania, ktoré k nemu boli pripojené - je zadanie jeho náhrady. Ak by náhrada musela vedieť niečo, čo na obrazovke nie je, hranica je na nesprávnom mieste.
2. Sledujte šípky, či nevznikol cyklus. Dva komponenty, ktoré vyžadujú jeden druhý, sa nedajú nasadzovať, testovať ani vymieňať nezávisle. Posledný z rozobratých príkladov ukazuje, ako to vyzerá a ako sa to rozbije.
3. Overte, že každý komponent má aspoň jedno rozhranie. Box, ku ktorému nič nie je pripojené, buď nie je komponent, alebo pre tento diagram nie je podstatný.
4. Prečítajte názvy rozhraní nahlas. Ak je niektoré pomenované podľa svojho súčasného poskytovateľa namiesto podľa schopnosti - IMainframeBilling namiesto IBilling - má zmluva dodávateľa zapečeného v sebe a výmena, ktorú diagram sľubuje, nebude taká čistá, ako vyzerá.

Pravý stĺpec nie je pedantéria o druhoch diagramov. Každá položka v ňom zväčší obrázok bez toho, aby odpovedala na otázku, kvôli ktorej bol diagram nakreslený, a každá dá diagramu druhý dôvod zastarať: diagram komponentov prežije zmenu platformy nedotknutý a tá istá kresba s dvoma AWS regiónmi nie.

Keď je kresba hotová, referenciu na každú značku na nej nájdete v článku symboly diagramu komponentov, a širšie zdôvodnenie, kedy sa tento druh diagramu vôbec oplatí, v sprievodcovi diagramom komponentov.