Često, kada zalazimo u svijet razvoja, nailazimo na pojam "poslovna logika" Ležerno se spominje na svakom sastanku, koristi se za opisivanje svega, od jednostavne if naredbe na frontendu do složenog upravljanja bazama podataka. Ova dvosmislenost nije za šalu, jer može dovesti do stvaranja sustava u kojima je sve pomiješano, što rezultira tim špageti kodom koji nas drži budnima noću kada je vrijeme za ažuriranje.
Kako biste izbjegli ove glavobolje, ključno je shvatiti da nisu svi kodovi za donošenje odluka jednaki. odvojene odgovornosti Korištenjem obrazaca poput slučajeva upotrebe i čiste arhitekture, osiguravamo da je jezgra vaše aplikacije robusna i neovisna o tome koristite li SQL Server, MongoDB ili je li sučelje web stranica ili mobilna aplikacija. Pogledajmo kako izgraditi ovaj sustav kako bi vaš softver bio zaista skalabilan.
Dekonstrukcija koncepta logike
Za početak čišćenja koda potrebno je razlikovati vrste odluka koje stroj donosi. poslovna logika To je ono što predstavlja stvarnost stvarnog svijeta; to su pravila koja bi vam dao stručnjak iz industrije bez ikakvog znanja o programiranju. Na primjer, da kupac s dugom većim od tisuću dolara ne može zatražiti veći kredit je... čisto poslovno pravilobez obzira na to je li pohranjen u JSON ili Oracle tablici.
S druge strane, imamo logika primjenešto je više poput orkestratora. Njegova je funkcija postaviti temelje: dohvatiti podatke iz baze podataka, pozvati poslovno pravilo i zatim spremiti rezultat. To neki nazivaju "metoda sendviča", gdje imamo nečisti ulazni sloj, čistu poslovnu jezgru u sredini i još jedan nečisti izlazni sloj.
Konačno, tu su i detalji implementacijeOvdje na scenu stupaju logika prezentacije (kao što je provjera ispravnog formata e-pošte ili odlučivanje hoće li se gumb prikazati) i logika infrastrukture (tehnička komunikacija s vanjskim API-jima ili datotečnim sustavom). Ti elementi su sekundarni detalji to bi se trebalo moći promijeniti bez dodirivanja ijedne linije jezgre sustava.
Problem čudovišnih sučelja
U mnogim projektima uobičajeno je stvoriti golemo servisno sučelje, kao što je IClientServicekoji sadrži apsolutno svaku moguću radnju koju kupac može poduzeti. U početku se čini kao dobra ideja jer slijedimo SOLID principe, ali s vremenom taj razred postaje čudovište od tisuću redaka što je prava muka za čitanje i održavanje.
Rješenje leži u pobjedi. veća granularnostUmjesto jednog, masivnog sučelja, svaku radnju možemo razbiti u zasebnu klasu. Tu dolaze do izražaja slučajevi upotrebe: svaka klasa predstavlja jedinstveno i specifično djelovanje koje korisnik može izvršiti, osiguravajući da svaka komponenta ima samo jednu odgovornost.
Učinkovita implementacija slučajeva upotrebe
Kako bi se izbjeglo ovisnost o specifičnim klasama i održala inverzija upravljanja, idealno rješenje je definirati generičko sučelje, na primjer IUseCase<TRequest, TResponse>Na taj način standardiziramo način na koji svaki slučaj upotrebe prima podatke i vraća odgovor, eliminirajući potrebu za stvaranjem desetke pojedinačnih sučelja za svaku akciju sustava.
Da bismo ovo učinili još čišćim, možemo uvesti dispečer slučajeva upotrebeOvaj dodatni sloj interno rješava koji se slučaj upotrebe treba izvršiti na temelju zahtjeva, sprječavajući da kontroler postane zatrpan beskrajnim injekcijama ovisnosti i oslobađajući kod kontrolera. mnogo jasnije.
Prednosti ovog arhitektonskog pristupa
- Vrhunska provjerljivost: Budući da je logika izolirana od baze podataka i korisničkog sučelja, možete pisati jedinične testove koji se izvode u milisekundama bez potrebe za pokretanjem poslužitelja.
- Tehnološka neovisnost: Možete migrirati svoju bazu podataka ili promijeniti frontend okvir bez fundamentalna logika poslovanje je pogođeno.
- Samodokumentirajući kod: Samo pogledajte mapu Slučajevi upotrebe da biste točno saznali. što aplikacija radi bez potrebe za čitanjem internog koda.
- Prava ponovna upotreba: Isti slučaj upotrebe može se pokrenuti REST API-jem, planiranim zadatkom ili naredbenom konzolom.
Najbolje prakse za robustan dizajn
Kako bi se spriječilo propadanje ovog sustava, ključno je da slučajevi upotrebe ne ovise jedni o drugima čime se izbjegavaju kružne ovisnosti. Također se preporučuje da vraćaju modele domena, a ne usmjeravaju entitete iz baze podataka, čime se održava vodonepropusnost slojeva.
Što se tiče rukovanja greškama, najelegantniji pristup je korištenje objekti rezultata (Uzorak rezultata) umjesto bacanja iznimki za kontrolu tijeka poslovanja. To čini put koda predvidljivijim i sprječava prekid aplikacije zbog pogrešaka koje su se strogo predviđeno po logici.
Usvajanje strukture temeljene na interaktoru i pravilno odvajanje jezgre sustava od tehničkih detalja omogućuje softveru fleksibilnost u suočavanju s promjenama na tržištu. Davanjem prioriteta isključivu odgovornost A razdvajanjem transformiramo rigidne aplikacije u agilne sustave koji olakšavaju timski rad i osiguravaju dugoročno održivu kvalitetu koda.