Jak nakreslit diagram komponent

Než cokoli nakreslíte, sepište seznam. Ne svých modulů, ne svých složek - částí systému, které by šlo reálně vyměnit za jinou implementaci: koupené místo postavené, přepsané jiným týmem nebo provozované někým jiným.

Právě tahle otázka je celý filtr. Složka není komponenta a třída taky ne; věc s hranicí, kterou byste uměli předat dodavateli, ano. Reportovací systém v tomhle článku jich dal čtyři: dashboard, plánovač, který spouští reporty přes noc, samotnou službu reportů a adaptér, který mluví s datovým skladem.

Umístěte části a odolejte pokušení je spojit. Kreslit šipky teď znamená kreslit je mezi komponentami a čára z Dashboardu rovnou do Služby reportů říká jen „tyhle dvě jsou nějak zapojené“, což je právě ta vágnost, kterou diagram komponent existuje odstranit.

Rozvržení tu stojí za třicet sekund: dejte spotřebitele na jednu stranu a poskytovatele na druhou. Každý diagram v téhle sérii je kreslený zleva doprava, se závislostmi tekoucími jedním směrem, protože čtenář pak ověří směr pohledem místo sledování každé čáry.

U každého boxu se zeptejte, na co se smí spolehnout někdo zvenčí, a to pojmenujte. Tady IReports a IWarehouse - jedna smlouva na schopnost, ne jedna na spotřebitele. Připojte ji realizací: přerušovaná čára, prázdný trojúhelník, mířící na rozhraní.

Právě v tomhle kroku se děje skutečný návrh a právě tenhle krok lidé přeskakují. Pojmenování smlouvy vás nutí rozhodnout, co je veřejné, a hádka, která následuje - „patří export do CSV do IReports, nebo ne?“ - je hádka, kterou se vyplatí svést dřív, než na ni dva týmy odpovědí v kódu rozdílně.

Teď druhá polovina a ta, která nese informaci: které smlouvy každá komponenta potřebuje? Nakreslete závislost - přerušovaná čára, otevřený hrot - z komponenty na rozhraní, které vyžaduje. Výsledek je diagram na začátku článku.

Ve chvíli, kdy ty šipky dopadnou, se zviditelní dvě věci. Dashboard i plánovač míří na IReports, takže jeho změna je teď viditelně změnou pro dva spotřebitele. A služba reportů míří na IWarehouse, ne na adaptér, takže adaptér jde vyměnit, aniž by si toho služba všimla - což je buď to, co jste zamýšleli, nebo objev, který stojí za to udělat teď.

Diagram komponent je hotový, když je přežije. Zaberou minutu a každá z nich odhalila skutečný problém častěji, než prošla načisto.

1. Zakryjte box dlaní. To, co zbude - rozhraní, která k němu byla připojená - je zadání jeho náhrady. Kdyby náhrada musela vědět něco, co na obrazovce není, je hranice na špatném místě.
2. Sledujte šipky, jestli nevznikl cyklus. Dvě komponenty, které vyžadují jedna druhou, nejdou nasazovat, testovat ani vyměňovat nezávisle. Poslední z rozebraných příkladů ukazuje, jak to vypadá a jak se to rozbije.
3. Ověřte, že každá komponenta má aspoň jedno rozhraní. Box, ke kterému nic není připojené, buď není komponenta, nebo pro tenhle diagram není podstatný.
4. Přečtěte názvy rozhraní nahlas. Pokud je některé pojmenované podle svého současného poskytovatele místo podle schopnosti - IMainframeBilling místo IBilling - má smlouva dodavatele zapečeného v sobě a výměna, kterou diagram slibuje, nebude tak čistá, jak vypadá.

Pravý sloupec není pedanterie o druzích diagramů. Každá položka v něm zvětší obrázek, aniž by odpověděla na otázku, kvůli které byl diagram nakreslený, a každá dá diagramu druhý důvod zastarat: diagram komponent přežije změnu platformy nedotčený a tatáž kresba se dvěma AWS regiony ne.

Když je kresba hotová, referenci ke každé značce na ní najdete v článku symboly diagramu komponent, a širší zdůvodnění, kdy se tenhle druh diagramu vůbec vyplatí, v průvodci diagramem komponent.