Arhitektonski dug rijetko se pojavljuje kao dramatičan neuspjeh. Češće se pojavljuje kao bezazlena iznimka: još jedan uvjet u kontroleru, jedna krajnja točka koja izravno upituje tablicu, jedno Docker zaobilazno rješenje koje će se „očistiti kasnije”. Svaki izbor može biti razuman zasebno. Zajedno, običan rad čine sporijim, rizičnijim i težim za objasniti.

To je stvarni trošak arhitektonskog duga. Ne čini samo kod neurednim. Smanjuje sposobnost tima da s pouzdanjem mijenja sustav. Na kraju, mala značajka zahtijeva praćenje obrađivača zahtjeva, servisnih klasa, radnika reda, okidača baze podataka i konfiguracije specifične za okruženje samo da bi se odgovorilo na osnovno pitanje: gdje bi se takvo ponašanje trebalo nalaziti?

Arhitektonski dug više je od starog koda

Tehnički dug često se opisuje kao prečaci u implementaciji. Arhitektonski dug je širi: to je akumulirano nepodudaranje između načina na koji se sustav treba razvijati i načina na koji su organizirane njegove granice, ovisnosti i tokovi podataka.

PHP aplikacija može biti uredno formatirana, dobro testirana, a ipak nositi ozbiljan arhitektonski dug. Razmotrite bazu koda u kojoj svaki kontroler sadrži validaciju, autorizaciju, poslovna pravila, upite prema bazi podataka i pozive API-jima trećih strana. Možda ništa nije vidljivo pokvareno, ali svaka nova krajnja točka učvršćuje strukturu u kojoj se HTTP aspekti i ponašanje domene ne mogu odvojiti.

Znakovi upozorenja obično su ponašajni, a ne estetski:

• Male promjene zahtijevaju izmjene u nepovezanim modulima.
• Timovi izbjegavaju nadogradnje jer su ovisnosti previše isprepletene.
• Ispravci performansi postaju rizični jer nije jasno tko je vlasnik upita.
• Testovi zahtijevaju opsežne fixturee, kontejnere ili mockove kako bi pokrili jednostavna pravila.
• Produkcijske incidente teško je izolirati jer se odgovornosti preklapaju.

Nijedan od ovih signala ne znači da je potrebno ponovno napisati sustav. Znače da je sustav počeo obračunavati kamate.

Najprije pronađite skupe putanje

Pokušaj poboljšanja svega odjednom pouzdan je način za stvaranje poremećaja bez značajnog napretka. Arhitektonski dug treba odrediti prema učestalosti promjena, utjecaju neuspjeha i dosegu ovisnosti.

Počnite s putanjama koje su istodobno važne i često se mijenjaju: tijekovi naplate, autentikacija, integracije naplate, ažuriranja zaliha, generiranje izvještaja ili API krajnje točke o kojima ovisi svaki klijent. Ta područja nude koristan povrat jer jasniji dizajn poboljšava i sadašnji i budući rad.

Mapirajte odgovornosti, ne samo datoteke

Stablo direktorija govori malo o stvarnoj arhitekturi. Umjesto toga, pratite reprezentativni zahtjev od ulazne točke do nuspojave. Za API krajnju točku utvrdite gdje validira ulaz, odlučuje o poslovnim pravilima, čita ili zapisuje podatke, emitira događaje i komunicira s vanjskim servisima.

Ako metoda kontrolera obavlja sve te poslove, postala je istodobno koordinacijska točka i poslovni sloj. Prvo praktično poboljšanje jest izdvojiti slučaj upotrebe na razini aplikacije koji operaciju izražava poslovnim terminima:

final class PlaceOrder
{
    public function __construct(
        private OrderRepository $orders,
        private PaymentGateway $payments,
    ) {}

    public function handle(PlaceOrderRequest $request): Order
    {
        $order = Order::fromRequest($request);

        $this->payments->authorize($order->total(), $request->paymentToken());
        $this->orders->save($order);

        return $order;
    }
}

Ovo nije zahtjev za razrađenim slojevima. To je način da se operacija učini testabilnom i da se budućim promjenama pruži stabilno mjesto. HTTP kontroler može prevesti zahtjev u PlaceOrderRequest; slučaj upotrebe upravlja tijekom rada; infrastruktura implementira pojedinosti pohrane i pristupnika.

Otplaćujte dug kroz spojeve

Najsigurnija strategija refaktoriranja obično je stvoriti spoj oko postojećeg ponašanja, a zatim postupno premještati odgovornost kroz taj spoj. Spoj može biti sučelje, granica modula, namjenski objekt upita ili servis s uskim ugovorom.

Primjerice, ako aplikacijski kod ima SQL raspršen po nekoliko servisa, nemojte odmah dizajnirati veliku hijerarhiju repozitorija. Počnite s upitom koji uzrokuje ponavljajuće probleme. Dodijelite mu izričitog vlasnika, dokumentirajte njegove ulaze i izlaz te testirajte njegovo ponašanje na stvarnoj bazi podataka na isti način na koji će se izvoditi u produkciji.

Ta je razlika važna. Apstrakcije baze podataka korisne su kada pojašnjavaju pravila ili izoliraju infrastrukturne aspekte. Štetne su kada prikrivaju trošak upita, granice transakcija, ponašanje zaključavanja ili mogućnosti specifične za bazu podataka. Repozitorij koji nameće neučinkovit slijed čitanja i zapisa nije čišća arhitektura; on je skupa maska.

Transakcije učinite namjernima

Arhitektonski dug često se skriva u nedosljednom rukovanju transakcijama. Tijek rada koji ažurira narudžbu, smanjuje zalihe i zapisuje zapis revizije trebao bi imati jasno definiranu atomsku granicu. Ako također šalje e-poštu ili poziva vanjskog pružatelja plaćanja, ti učinci zahtijevaju pažljivo redoslijedanje jer se ne mogu automatski poništiti zajedno s bazom podataka.

Pragmatičan obrazac jest potvrditi osnovno stanje baze podataka, zabilježiti događaj u istoj transakciji i taj događaj obraditi asinkrono. Važna nije određena značajka okvira. Važno je učiniti ponašanje pri neuspjehu izričitim: što se ponovno pokušava, što je idempotentno i što se događa ako radnik dvaput obradi istu poruku?

Idempotentnost pripada dizajnu, a ne zakrpi nakon incidenta. Povratni poziv plaćanja sa stabilnim identifikatorom događaja može sigurno zabilježiti da je već obrađen. Ponovni pokušaj bez takve zaštite može stvoriti duplicirane račune, duplicirane obavijesti ili nedosljedno stanje.

Zadržite operacije kao dio arhitekture

Održivost se proteže izvan PHP klasa. Docker konfiguracija, varijable okruženja, migracije, redovi, predmemorije i mogućnost promatranja sve su arhitektonske površine. Servis koji radi samo zato što programeri pamte nedokumentirani slijed pokretanja nosi operativni dug.

Učinite podržani put očitim. Lokalno postavljanje trebalo bi koristiti iste glavne ovisnosti kao i implementacija. Konfiguracija bi trebala biti izričita i rano validirana. Migracije bi trebale biti unaprijed kompatibilne gdje je moguće, osobito kada se uvođenje aplikacije i promjena sheme ne mogu dogoditi u potpuno istom trenutku.

Primjerice, dodavanje stupca baze podataka koji ne dopušta null može biti sigurnije kao slijed: dodajte stupac u kompatibilnom obliku, implementirajte kod koji ga zapisuje, popunite postojeće zapise, a zatim nametnite strože ograničenje. To je manje glamurozno od jedne migracije, ali poštuje stvarnost da se aktivni sustavi mijenjaju u fazama.

Mjerite napredak prema uklonjenom trenju

Nemojte smanjenje duga mjeriti brojem premještenih datoteka ili uvedenih obrazaca. Mjerite je li rutinski rad postao lakši: poslovno se pravilo može testirati bez pokretanja cijele aplikacije, spor upit ima jednog vidljivog vlasnika, implementacija ima poznatu putanju vraćanja na prethodno stanje ili se API ugovor može razvijati bez iznenađivanja svakog korisnika.

Dobra arhitektura nije najapstraktniji dizajn. To je dizajn koji sljedeću važnu promjenu čini razumljivom. Inženjerima daje mjesta za smještanje novog ponašanja, granice koje sprječavaju slučajno povezivanje i dovoljno operativne jasnoće za oporavak kada pretpostavke zakažu.

Arhitektonski dug postaje opasan kada je nevidljiv i kada se tretira kao tuđi budući problem. Učinite ga vidljivim, odaberite jednu skupu putanju i poboljšajte je dok isporučujete stvarni rad na proizvodu. Tako održivost prestaje biti težnja i postaje sposobnost koju projekt može nastaviti koristiti.