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.
„Měli byste být loajální k firmě, sdílet její cíle a přijmout její hodnoty.“ K tomu ale nedojde. Nechápejte mě špatně, neříkám „To neudělám“, říkám, že to se nestane, nemůže se to stát, není to možné.
Lidé nejsou loajální k firmě, jsou loajální k lidem ve firmě díky kultuře, která je těmito lidmi vytvořena.