Návrh s možností dalšího vývoje

Evoluční návrh s možností dalšího vývoje je klíčem k nepřetržitým inovacím.

Všechny úspěšné aplikace se v průběhu času mění, ať už kvůli opravám chyb, přidávání nových funkcí, zavádění nových technologií, nebo převodu stávajících systémů na více škálovatelné a odolné. Pokud jsou všechny součásti aplikace úzce svázány, zavedení změn do systému je velmi obtížné. Změna v jedné části aplikace může narušit jinou část nebo způsobit změny, které se rozšíří celým základem kódu.

Tento problém se neomezuje jen na monolitické aplikace. Aplikace může být rozložená na služby, ale stále vykazuje určitou úzkou svázanost, která nechává systém strnulý a křehký. Ale když jsou služby navržené tak, aby se vyvíjely, týmy můžou inovovat a nepřetržitě poskytovat nové funkce.

Mikroslužby se stávají oblíbeným způsobem, jak dosáhnout vývojového návrhu, protože řeší řadu zde uvedených aspektů.

Doporučení

Vynuťte vysokou soudržnost a volné vázání. Služba je soudržná, pokud poskytuje funkce, které logicky patří k sobě. Služby jsou volně vázané, pokud můžete změnit jednu službu beze změny druhé. Vysoká soudržnost obecně znamená, že změny v jedné funkci budou vyžadovat změny v jiných souvisejících funkcích, kde se všechny související funkce nacházejí v jedné službě. Pokud zjistíte, že aktualizace služby vyžaduje koordinované aktualizace dalších služeb, může to být signálem, že vaše služby nejsou soudržné. Jedním z cílů návrhu řízeného doménou (DDD) je identifikace těchto hranic.

Zapouzdřete znalosti domény. Když klient využívá službu, odpovědnost za vynucování obchodních pravidel domény by neměla padnout na klienta. Místo toho by měla služba zapouzdřovat všechny znalosti domény, které spadají do její odpovědnosti. Jinak musí obchodní pravidla vynucovat každý klient a skončíte se znalostí domény rozloženou mezi různé části aplikace.

Používejte asynchronní zasílání zpráv. Asynchronní zasílání zpráv představuje způsob, jak oddělit producenta zpráv od příjemce. Producent není závislý na příjemci, který reaguje na zprávu nebo podniká konkrétní akci. S architekturou publikování/odběru nemusí producent ani vědět, kdo zprávy spotřebovává. Nové služby můžou snadno využívat zprávy bez jakýchkoli úprav producenta.

Nezačleňujte znalosti domény do brány. Brány můžou být užitečné v architektuře mikroslužeb pro takové věci, jako je směrování žádostí, překlad protokolů, vyrovnávání zatížení nebo ověřování. Brány ale musí být omezené na tento typ funkcí infrastruktury. Neměly by implementovat žádné znalosti domény, aby se zabránilo vzniku silné závislosti.

Vystavte otevřená rozhraní. Vyhněte se vytváření vlastních vrstev překladu, které se nacházejí mezi službami. Místo toho by služba měla vystavit rozhraní API s dobře definovaným kontraktem rozhraní API. Rozhraní API musí mít verze, aby bylo možné rozhraní API rozvíjet při zachování zpětné kompatibility. Tímto způsobem můžete aktualizovat službu bez koordinace aktualizací pro všechny navazující služby, které jsou na ní závislé. Veřejně přístupné služby by měly vystavit rozhraní RESTful API přes protokol HTTP. Back-endové služby můžou z důvodu výkonu použít protokol zasílání zpráv typu RPC.

Provádějte návrh a testování proti kontraktům služeb. Pokud služby vystaví dobře definovaná rozhraní API, můžete provádět vývoj a testování proti těmto rozhraním API. Tímto způsobem můžete vyvíjet a testovat jednotlivé služby bez rozbíhání všech závislých služeb. (Samozřejmě budete stále muset provést integraci a zátěžové testování proti skutečným službám.)

Abstrahujte infrastrukturu od logiky domény. Nenechte logiku domény smíchat se s funkcemi souvisejícími s infrastrukturou, jako je zasílání zpráv nebo trvalost. Jinak budou změny v logice domény vyžadovat aktualizace vrstev infrastruktury a naopak.

Přesuňte obecně se vyskytující aspekty do samostatné služby. Například pokud několik služeb potřebuje ověřovat žádosti, může tuto funkci přesunout do vlastní služby. Pak byste mohli ověřovací službu vyvíjet – například přidáním nového toku ověřování – aniž byste se dotkli některé ze služeb, které ji používají.

Nasazujte služby nezávisle. Když tým DevOps může nasadit jednu službu nezávisle na jiných službách v aplikaci, k aktualizacím může docházet rychleji a bezpečněji. Opravy chyb a nové funkce jde vydávat v pravidelných intervalech. Navrhněte aplikaci a proces vydávání tak, aby se podporovaly nezávislé aktualizace.