Kadalasan, kapag sumisid tayo sa mundo ng pag-unlad, nababasa natin ang terminong "lohika sa negosyo" Ito ay basta-basta na lang ginagamit sa anumang pagpupulong, ginagamit upang ilarawan ang lahat mula sa isang simpleng pahayag na "kung" sa frontend hanggang sa kumplikadong pamamahala ng database. Hindi katawa-tawa ang kalabuang ito, dahil maaari itong humantong sa paglikha ng mga sistema kung saan ang lahat ay halo-halo, na nagreresulta sa isang spaghetti code na nagpapagising sa atin sa gabi kapag oras na para mag-update.
Para maiwasan ang mga sakit ng ulong ito, mahalagang maunawaan na hindi lahat ng kodigo sa paggawa ng desisyon ay pantay-pantay. magkakahiwalay na responsibilidad Sa pamamagitan ng paggamit ng mga pattern tulad ng Use Cases at Clean Architecture, tinitiyak namin na ang core ng iyong aplikasyon ay matatag at hindi nakadepende kung gumagamit ka man ng SQL Server, MongoDB, o kung ang interface ay isang website o isang mobile app. Suriin natin kung paano buuin ang sistemang ito upang ang iyong software ay tunay na maging scalable.
Pagbubuod ng Konsepto ng Lohika
Para simulan ang paglilinis ng code, kinakailangang pag-iba-ibahin ang mga uri ng desisyong ginagawa ng makina. lohika ng negosyo Ito ang kumakatawan sa realidad ng totoong mundo; ito ang mga patakarang ibibigay sa iyo ng isang eksperto sa industriya nang walang alam tungkol sa programming. Halimbawa, ang isang customer na may utang na higit sa isang libong dolyar ay hindi maaaring humiling ng karagdagang kredito ay isang purong tuntunin sa negosyonakaimbak man ito sa isang JSON o isang Oracle table.
Sa kabilang banda, mayroon tayong lohika ng aplikasyonna mas katulad ng orchestrator. Ang tungkulin nito ay itakda ang entablado: kunin ang data mula sa database, tawagin ang business rule, at pagkatapos ay i-save ang resulta. Ito ang tinatawag ng ilan na "paraan ng sandwich", kung saan mayroon tayong isang impurong input layer, ang purong business core sa gitna, at isa pang impurong output layer.
Sa wakas, may mga mga detalye ng pagpapatupadDito pumapasok ang lohika ng presentasyon (tulad ng pagpapatunay na ang isang email ay may tamang format o pagpapasya kung ang isang button ay ipinapakita) at lohika ng imprastraktura (teknikal na komunikasyon sa mga panlabas na API o sa file system). Ang mga elementong ito ay pangalawang detalye na dapat ay kayang baguhin nang hindi naaapektuhan ang kahit isang linya ng core ng sistema.
Ang problema ng mga interface ng halimaw
Sa maraming proyekto, karaniwan ang paglikha ng isang higanteng interface ng serbisyo, tulad ng isang IClientServicena naglalaman ng lahat ng posibleng aksyon na maaaring gawin ng isang customer. Sa una, tila magandang ideya ito dahil sinusunod namin ang mga prinsipyong SOLID, ngunit sa paglipas ng panahon ang klaseng iyon ay nagiging isang halimaw ng libu-libong linya na isang tunay na pagsubok na basahin at panatilihin.
Ang solusyon ay nasa panalo. mas malaking granularitySa halip na iisang malaking interface, maaari nating hatiin ang bawat aksyon sa isang hiwalay na klase. Dito pumapasok ang mga Use Case: ang bawat klase ay kumakatawan sa isang natatangi at tiyak na aksyon na kayang gampanan ng gumagamit, tinitiyak na ang bawat bahagi ay may iisang responsibilidad lamang.
Mahusay na Pagpapatupad ng mga Use Case
Upang maiwasan ang pagdepende sa mga partikular na klase at mapanatili ang inversion of control, ang mainam na solusyon ay ang pagtukoy ng isang generic interface, halimbawa IUseCase<TRequest, TResponse>Sa ganitong paraan, ini-standardize namin kung paano tumatanggap ng data at nagbabalik ng tugon ang bawat use case, na inaalis ang pangangailangang lumikha dose-dosenang mga indibidwal na interface para sa bawat aksyon ng sistema.
Para mas maging malinis ito, maaari tayong magpakilala ng dispatcher ng use caseAng karagdagang layer na ito ang panloob na nagre-resolba kung aling use case ang dapat isagawa batay sa kahilingan, na pumipigil sa controller na maging kalat sa walang katapusang dependency injections at nagpapalaya sa controller code. mas malinaw.
Mga kalamangan ng pamamaraang arkitektura na ito
- Superior na kakayahang masubukan: Dahil ang lohika ay nakahiwalay sa database at sa UI, maaari kang magsulat ng mga unit test na tumatakbo sa loob ng milliseconds nang hindi kinakailangang magsimula ng server.
- Teknolohikal na kalayaan: Maaari mong ilipat ang iyong database o baguhin ang frontend framework nang wala ang pangunahing lohika apektado ang negosyo.
- Kodigo sa pagdodokumento sa sarili: Tingnan mo lang ang folder na Use Cases para malaman mo nang eksakto. ano ang ginagawa ng app nang hindi kinakailangang basahin ang panloob na code.
- Tunay na muling paggamit: Ang parehong use case ay maaaring ma-trigger ng isang REST API, isang naka-iskedyul na gawain, o isang command console.
Pinakamahusay na mga kasanayan para sa matatag na disenyo
Upang maiwasan ang pagkasira ng sistemang ito, mahalaga na ang mga Kaso ng Paggamit huwag umasa sa isa't isa kaya naiiwasan ang mga paikot na dependency. Inirerekomenda rin na ibalik nila ang mga modelo ng domain at hindi idirekta ang mga entity mula sa database, sa gayon ay pinapanatili ang hindi tinatablan ng tubig ng mga patong.
Tungkol sa paghawak ng error, ang pinaka-eleganteng paraan ay ang paggamit ng mga resultang bagay (Result Pattern) sa halip na magtapon ng mga exception upang kontrolin ang daloy ng negosyo. Ginagawa nitong mas mahuhulaan ang code path at pinipigilan ang application na masira dahil sa mga error na dati nang mahigpit na hinuhulaan sa pamamagitan ng lohika.
Ang pag-aampon ng istrukturang nakabatay sa interactor at wastong paghihiwalay ng core ng sistema mula sa mga teknikal na detalye ay nagbibigay-daan sa software na maging flexible sa harap ng mga pagbabago sa merkado. Sa pamamagitan ng pagbibigay-priyoridad sa nag-iisang pananagutan At sa pamamagitan ng decoupling, binabago namin ang mga rigid application tungo sa mga agile system na nagpapadali sa pagtutulungan at tinitiyak ang pangmatagalang napapanatiling kalidad ng code.