Django apps: modularna arhitektura za aplikacije koje rastu

Django projekt može početi sa samo nekoliko modela, ali kroz vrijeme dobiti korisnike, dokumente, događaje, obavijesti, naplatu i integracije. Ako sav kod završava u jednoj aplikaciji, svaka izmjena postaje riskantnija. Rješenje nije nužno razbijanje svega na mikroservise: dobro definirane Django apps često su sasvim dovoljne.

Django project i Django app nisu isto

Projekt okuplja konfiguraciju, URL-ove i aplikacije, dok pojedina aplikacija predstavlja funkcionalnu cjelinu. U sustavu za rezervacije to mogu biti users, events, reservations i notifications. Nazivi nisu najvažniji. Važno je da svaka cjelina ima jasnu odgovornost i razumljive granice prema ostalima.

Nemojte automatski napraviti jednu aplikaciju po modelu. Korisnik i njegov profil često pripadaju istom području, dok rezervacije mogu uključivati više modela koji zajedno predstavljaju jedan poslovni proces. Granice odredite prema promjenama koje se događaju zajedno.

Razmišljajte kroz domenu

Prije strukture mapa nacrtajte tijek rada. Tko kreira događaj, kako se rezervira mjesto, tko šalje potvrdu i što se događa kad se termin otkaže? Iz odgovora nastaju domenske cjeline. Kada se pravilo promijeni, trebalo bi biti jasno gdje tražiti odgovarajući kod.

Za jednostavan projekt modeli i viewovi u standardnim datotekama mogu biti dovoljni. Kada narastu, smisleno je podijeliti ih u pakete: models/, views/, services/, selectors/ ili druge jasno dogovorene strukture. Ne postoji jedna službena obvezna arhitektura za sve Django projekte.

Ovisnosti između aplikacija

Najveći problem modularizacije nije broj mapa, nego međusobna povezanost. Ako events ovisi o notifications, a notifications u svojoj osnovnoj logici ovisi o events, promjene se počinju širiti na neočekivana mjesta. Bolje je odrediti koji modul pokreće radnju i kojim sučeljem komunicira s ostalima.

Za jednostavan događaj nakon spremanja moguće je koristiti signal, ali signali nisu uvijek najbolji izbor za kritičnu poslovnu logiku. Kada je bitno da rezervacija i slanje obavijesti imaju kontrolirano ponašanje, eksplicitna servisna funkcija i pozadinski zadatak često su čitljiviji i lakši za testiranje.

Baza i migracije ostaju zajednička odgovornost

Više Django apps ne znači automatski zasebne baze. Većina manjih poslovnih aplikacija dobro funkcionira sa zajedničkim PostgreSQL sustavom i jasno definiranim modelima. Pazite na kružne ovisnosti migracija, promjene primarnih ključeva i prijelaze koji zahtijevaju migraciju podataka.

Modularnost ne oslobađa od integracijskih testova. Rezervacija možda prolazi test u svojoj aplikaciji, ali se još mora provjeriti da promjena statusa ispravno ažurira izvještaj i šalje odgovarajuću obavijest.

Koliko modula je dovoljno?

Dobar znak je da novi član tima može brzo pronaći kod za određeni proces. Loš znak je ako svaka sitna promjena zahtijeva prolazak kroz deset apstrakcija. Počnite s malim brojem jasnih aplikacija i dijelite ih tek kada se pojave stvarni razlozi. Modularna arhitektura treba smanjiti trošak budućih promjena, a ne povećati složenost radi uredne strukture direktorija.

Primjer podjele aplikacije za ustanovu

Sustav koji vodi događaje i rezervacije može imati modul za korisnike, modul za događaje, modul za rezervacije i modul za obavijesti. Granice nisu strogo određene brojem modela. Rezervacija može sadržavati mjesta, status, korisnika i povijest, a sve je to logički dio jedne poslovne cjeline. Ako se obrada rezervacija mijenja, želimo da promjena što manje utječe na prijavu korisnika ili izgled kalendara.

Modularnost također olakšava testiranje. Testovi modula za rezervacije mogu potvrditi da su dva pokušaja rezervacije istog posljednjeg mjesta pravilno obrađena, dok integracijski test provjerava potvrdu e-poštom. Bez takvih testova podjela u mape ne daje stvarnu sigurnost.

Česta pitanja

Treba li svaka Django app vlastitu bazu? Ne. Više modula često dobro radi u jednoj relacijskoj bazi.

Je li modularni monolit lošiji od mikroservisa? Ne nužno. Za manji tim i povezane poslovne procese često je jednostavniji za razvoj i održavanje.

Kada izdvojiti novi modul? Kada postoji jasna poslovna odgovornost, zaseban životni ciklus ili potreba za ograničavanjem ovisnosti, a ne samo zato što je datoteka narasla.

Praktična provjera modularnosti projekta

Modularan kod treba olakšati razvoj, a ne dodati nepotrebne slojeve. Dobar test je zadatak koji promijeni jedno poslovno pravilo, primjerice način potvrđivanja rezervacije. Ako za malu promjenu morate izmijeniti deset nepovezanih modula, granice aplikacija možda nisu dobro postavljene.

• Može li se iz naziva Django aplikacije razumjeti kojem poslovnom području pripada i tko je za njega odgovoran?
• Jesu li izbjegnute kružne ovisnosti i neočekivani uvozi koji otežavaju pokretanje testova ili migracija?
• Nalaze li se pravila transakcija i kritične promjene stanja na jasnom, lako testiranom mjestu?
• Jesu li prava pristupa dosljedna kada se isti zapis obrađuje iz administracije, API-ja i javnog portala?
• Može li novi programer pronaći gdje se mijenja konkretno pravilo bez dugog pretraživanja cijelog repozitorija?
• Postoje li testovi koji provjeravaju ne samo module odvojeno, nego i glavne poslovne procese preko više modula?

Ako je odgovor uglavnom potvrdan, modularnost vjerojatno donosi korisnu fleksibilnost, bez potrebe za preranim prijelazom na mikroservise.