PHP pozadinski sustav rijetko zataji zato što je tim odabrao „pogrešan” okvir. Zataji kada se kodna baza neprimjetno počne teže mijenjati nego što je poslovanje teško razumjeti. Novi zahtjevi dolaze kao mali zahtjevi: dodajte pružatelja plaćanja, izložite krajnju točku, zadržite više podataka za reviziju, podržite drugu klijentsku aplikaciju. Nekoliko mjeseci kasnije ti su zahtjevi ostavili aplikacijsku logiku raspršenu po kontrolerima, ORM modelima, poslovima u redu čekanja i okidačima baze podataka.

Neprekidna evolucija stvarni je arhitektonski zahtjev. Cilj nije predvidjeti svaku buduću značajku. Cilj je stvoriti jasne granice, sigurne putove za promjene i dovoljno operativne discipline kako bi sljedeća promjena ostala uobičajen posao, a ne rizična ekspedicija.

Započnite s granicama, a ne apstrakcijama

Većina PHP aplikacija započinje razumno: rute pozivaju kontrolere, kontroleri pozivaju servise, servisi trajno pohranjuju modele. Problem počinje kada ti slojevi postanu oznake umjesto granica. Kontroler koji izračunava cijene, šalje poštu, upisuje u nekoliko tablica i poziva API treće strane možda je i dalje „tanak” po duljini datoteke, ali upravlja s previše odluka.

Trajniji oblik jest organizirati kod oko poslovnih sposobnosti. Na primjer, tijek obrade narudžbe može imati aplikacijski servis koji koordinira slučaj uporabe, domenske objekte koji izražavaju pravila i infrastrukturne prilagodnike za trajnu pohranu ili udaljene API-je. Nazivi su manje važni od smjera ovisnosti: poslovna pravila ne bi trebala trebati znati dolaze li podaci iz MySQL-a, Redisa ili HTTP klijenta.

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

    public function handle(PlaceOrderRequest $request): Order
    {
        $order = Order::fromItems($request->items());

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

        return $order;
    }
}

Ovo nije argument za razrađeno domensko modeliranje posvuda. Krajnjoj točki za izvještavanje možda je potreban samo usmjeren servis za upite. Korisna je razlika između koda koji predstavlja poslovnu odluku i koda koji obavlja tehnički detalj. Držite ih odvojeno ondje gdje je promjena vjerojatna, skupa ili regulirana.

Dizajnirajte API-je kao ugovore koji mogu dobro starjeti

API nije samo transportni sloj. Kada drugi sustav ovisi o njemu, postaje ugovor proizvoda. Taj ugovor zahtijeva promišljene zadane postavke: stabilne identifikatore, predvidljive oblike pogrešaka, paginaciju za kolekcije i izričitu validaciju.

Verzioniranje je ponekad potrebno, ali ne bi trebalo biti prvi odgovor na svaki dodatak. Dodavanje neobaveznog polja odgovora obično je kompatibilno. Preimenovanje polja, promjena njegova značenja ili pretvaranje sinkrone operacije u asinkronu nije. Nekompatibilne promjene tretirajte kao migracije: dokumentirajte ih, podržite prijelazno razdoblje gdje je praktično i mjerite usvajanje među korisnicima prije uklanjanja starog ponašanja.

Učinite semantiku neuspjeha dijelom dizajna

Klijenti trebaju razlikovati neispravan unos od nedostajućeg resursa, sukoba i privremenog neuspjeha. Također trebaju moći sigurno ponovno pokušati. Za operacije poput stvaranja plaćanja ili dodjele računa prihvatite ključ idempotentnosti i pohranite rezultat povezan s njime. Mrežni istek vremena ne bi smio jednu korisničku radnju pretvoriti u dva zapisa.

Za izlazne integracije pretpostavite da su neuspjesi uobičajeni. Postavite vremenska ograničenja za povezivanje i ukupno trajanje, pažljivo klasificirajte pogreške koje se mogu ponovno pokušati te koristite ograničene ponovne pokušaje s postupnim povećanjem razmaka. Ponovno pokušavanje nakon pogreške validacije troši resurse; ponovno pokušavanje nakon prolaznog neuspjeha pristupnika može biti prikladno. Ako se posao može odgoditi, stavite ga u trajni red čekanja i učinite radnika također idempotentnim.

Neka baza podataka štiti ono što je važno

Validacija aplikacije poboljšava korisničko iskustvo, ali ne može biti jedina linija obrane. Istodobni zahtjevi, pozadinski poslovi, uvozi i administrativne skripte mogu zaobići provjeru na razini kontrolera. Ograničenja baze podataka štite invarijante na mjestu gdje podaci postaju trajni.

• Koristite strane ključeve kada odnosi moraju ostati valjani.
• Koristite jedinstvena ograničenja za identitete i pravila deduplikacije.
• Koristite transakcije za promjene koje moraju zajedno uspjeti ili ne uspjeti.
• Dodajte indekse na temelju stvarnih obrazaca upita, a ne prema stupcima tablice iz navike.

Promjene sheme zaslužuju isti oprez kao i promjene koda. Dajte prednost aditivnim migracijama: dodajte stupac koji dopušta NULL, implementirajte kod koji ga upisuje, popunite postojeće podatke u kontroliranim paketima, zatim uvedite stroža ograničenja kada su podaci spremni. Izbjegavajte implementaciju koja pretpostavlja da je migracija dovršena posvuda u potpuno istom trenutku. U postupnim implementacijama stare i nove verzije aplikacije mogu raditi usporedno.

ORM-ovi mogu ubrzati svakodnevnu trajnu pohranu, ali ne uklanjaju ponašanje baze podataka. Pregledajte generirane upite, pazite na slučajne upite po pojedinačnim redovima te upotrijebite izričita spajanja, unaprijed učitavanje ili namjenske upite za čitanje kada to obrazac pristupa zahtijeva. Čist objektni model vrijedan je; neispitan plan upita i dalje je produkcijski rizik.

Zapakirajte izvođenje, a konfiguraciju držite izvan njega

Docker je najkorisniji kada okruženja čini ponovljivima. Slika spremnika trebala bi sadržavati aplikaciju i njezine ovisnosti tijekom izvođenja, dok vrijednosti specifične za okruženje ostaju konfiguracija. Ovisnosti za izgradnju treba, kada je moguće, odvojiti od završne slike za izvođenje, a produkcijske slike trebale bi izbjegavati alate namijenjene samo razvoju.

FROM php:8.3-cli AS build
WORKDIR /app
COPY composer.json composer.lock ./
RUN composer install --no-dev --prefer-dist --no-interaction
COPY . .

FROM php:8.3-cli
WORKDIR /app
COPY --from=build /app /app
CMD ["php", "bin/console", "app:worker"]

Ovaj je primjer namjerno nepotpun: stvarnoj slici možda će trebati PHP proširenja, web-poslužitelj ili upravitelj procesa te korak zagrijavanja predmemorije specifičan za okvir. Važno je načelo da izgradnja treba biti ponovljiva iz deklariranih ulaza. Nemojte ugrađivati vjerodajnice u slike i nemojte se oslanjati na promjenjivi direktorij poslužitelja kao na nedeklariranu ovisnost.

Performanse počinju vidljivošću

Rad na performansama često je pogrešno usmjeren jer timovi optimiziraju ono što se čini sporim umjesto onoga što jest sporo. Uspostavite vidljivost vremena zahtjeva, stopa pogrešaka, dubine reda čekanja, latencije baze podataka i sporih upita prije širokih promjena. Zatim pratite zahtjev kroz njegove skupe granice: udaljene pozive, serijalizaciju, pristup datotečnom sustavu, promašaje predmemorije i upite baze podataka.

Predmemoriranje je kompromis između brzine i svježine, a ne univerzalni lijek. Predmemorirajte podatke s jasnim modelom vlasništva i strategijom poništavanja. Ako je poništavanje teško, kratko vrijeme života može biti sigurnije od pretvaranja da su podaci trajni. Za skup posao razmotrite asinkronu obradu, ali jasno komunicirajte status umjesto da klijente ostavljate da nagađaju je li zahtjev uspio.

Učinite promjenu rutinskom operacijom

Održivost nije estetska urednost. To je sposobnost pouzdane ispravne promjene. Mali, kohezivni moduli pomažu, ali i testovi na važnim granicama: test API ugovora, integracijski test repozitorija prema stvarnoj bazi podataka i usmjereni testovi poslovnih pravila. Testovi koji samo odražavaju detalje implementacije obično otežavaju refaktoriranje.

Operativna spremnost pripada istom razgovoru. Svaki servis trebao bi imati korisne zapisnike, korelacijske identifikatore gdje zahtjevi prelaze granice, provjere ispravnosti koje odražavaju njegove ovisnosti i plan povratka za rizična izdanja. Implementacija nije dovršena kada se kod izvodi; dovršena je kada tim može utvrditi ponaša li se ispravno.

Najotporniji pozadinski sustav nije onaj s najviše obrazaca. To je onaj čija sljedeća nužna promjena ima očito, testabilno i vidljivo mjesto gdje može živjeti.

PHP ostaje praktičan temelj za sustave koji se razvijaju jer jezik i ekosustav omogućuju timovima prijelaz od jednostavne aplikacije zahtjev–odgovor do redova čekanja, spremnika, tipiziranih servisa i disciplinirane implementacije bez napuštanja platforme. Arhitektura koja traje nije zamrznuti dijagram stoga. To je skup izbora koji kod, podatke i operacije održava spremnima za sljedeći stvarni zahtjev.