Softwarová komplexita 2
V návaznosti na předchozí článek budu pokračovat komplexitou škálování, komplexitou podpůrných částí a náhodnou komplexitou – typy, které je možné managovat, redukovat a dokonce i odstranit.
V návaznosti na předchozí článek budu pokračovat komplexitou škálování, komplexitou podpůrných částí a náhodnou komplexitou – typy, které je možné managovat, redukovat a dokonce i odstranit.
Komplexita je úhlavní nepřítel softwarového designu a architektury. Primárním úkolem softwarového architekta je odstranit, redukovat a spravovat komplexitu – v tomto pořadí. Ale co když samotná podstata problému, který řešíte, je komplexní? Co potom? Co vlastně znamená řídit komplexitu a co je vůbec komplexita?
Existuje několik typů softwarové komplexity, a každý typ vyžaduje jiný přístup.
Vývojáři používají slovo "abstrakce" běžně, nicméně často s omezeným chápáním významu. Pro většinu byl koncept abstrakce zastíněn jejím použitím v některých jazycích pro označení metody nebo třídy, která musí být děděna a přetížena. Stejně tak "použij abstrakci" pro spoustu developerů znamená "napiš abstraktní třídu".
Abstrakce je jednou z nejdůležitějších technik pro docílení decouplingu a stabilizaci veřejného rozhraní na všech úrovních.
Existuje několik způsobů, jak vytvořit modulit, a jeden z nich si dnes ukážeme. Ty důležité části, na které se dnes zaměříme, jsou: aplikační vrstva, business vrstva, fasády a repositáře, event bus/broker, CQ router a utilities.
Pochopení rolí a rozdělení těchto částí je základem pro napsání kódu, který neskončí jako "big ball of mud".
Monolitický styl má špatnou reputaci, nicméně je vhodnou volbou pro menší aplikace. Problémem není nutně monolit, ale spíš způsob jeho implementace.
Proč zvolit monolit namísto distribuované architektury (např. microservices)? Networking mezi jednotlivými komponentami představuje novou sadu problémů. Existují stejně benefity jako nevýhody.
Modulární monolit – modulit je vhodná volba, jak začít psát aplikaci.