Ky do të jetë një tregim mbi përshtypjen e librit, si dhe do të shqyrtohen disa koncepcione dhe njohuri që, falë këtij libri, janë mësuar.
Arkitektura
A mund t'i jepni njĂ« pĂ«rgjigje tĂ« qartĂ« pyetjes, çfarĂ« Ă«shtĂ« arkitektura? ĂfarĂ« Ă«shtĂ« arkitektura nĂ« kontekstin e programimit dhe dizajnit? Cila Ă«shtĂ« roli i saj? Ka shumĂ« paqartĂ«si nĂ« kĂ«tĂ« term. Duket se gjithçka Ă«shtĂ« e qartĂ«, por gjithsesi Ă«shtĂ« disi abstrakte dhe pa saktĂ«si. Martin mendon, dhe unĂ« e pajtohem me tĂ«, se njĂ« aplikacion ka dy pĂ«rbĂ«rĂ«s:
- Sjellja (behavior) â funksionet dhe detyrat qĂ« programi (komponenti, shĂ«rbimi) i kryen.
- Arkitektura â ky term kryesisht ka tĂ« bĂ«jĂ« me ndryshimin e aplikacionit.
Por edhe nĂ«se aplikacioni kryen shumĂ« mirĂ« detyrĂ«n qĂ« duhet, kjo nuk nĂ«nkupton aspak qĂ« ai ka njĂ« arkitekturĂ« tĂ« mirĂ«. Arkitektura â nuk Ă«shtĂ« pĂ«r sjelljen e aplikacionit. Arkitektura â Ă«shtĂ« pĂ«r lehtĂ«sinĂ« e ndryshimit, arkitektura â Ă«shtĂ« pĂ«r lehtĂ«sinĂ« e shpĂ«rndarjes, arkitektura â Ă«shtĂ« pĂ«r pavarĂ«sinĂ« e zhvillimit. Arkitektura â Ă«shtĂ« pĂ«r shpejtĂ«sinĂ« me tĂ« cilĂ«n e kupton njĂ« person i ri nĂ« ekip.
Dhe ja se si të ndërtojmë këtë arkitekturë, si të eliminojmë dhimbjen e kokës me ndryshimin e vogël të kërkesave nga PM ose nga palët e interesuara: për këtë do të flasë libri.
Për autorët
Para se të flasë për këtë libër, dëshiroj të them pak për veten.
Aktualisht jam një Zhvillues Strong Junior, i specializuar në zhvillimin e shërbimeve përmes ASP .NET CORE.
Kam punuar për një vit në një "galerë", dhe duket se po i përballoj pak nga pak.
Këtë libër e kam lexuar tashmë 2 herë dhe rekomandoj të lexojmë të gjithëve:
- zhvilluesve të sistemeve embeded;
- front-end developer të;
- back-end developer të;
- edhe devops.
Përfundimisht, për të gjithë ata që janë ndonjëherë të lidhur me zhvillimin e softuerit, nënkuptoj zhvillimin direkt të ndryshme atje. Sipas meje, nuk përfshijmë Sales dhe PM këtu (megjithëse do të ishte gjithashtu e dobishme të dihej se pse një dev shpesh shpenzon dy herë më shumë kohë për një detyrë), rekomandoj të lexohet ky libër.
Dhe tani do të përpiqem të argumentoj pse mendoj kështu.
Pak njĂ« informacion tĂ« vogĂ«l rreth autorit tĂ« kĂ«saj libri (sepse pĂ«r mua autoriteti i atij qĂ« shkruan ka shumĂ« rĂ«ndĂ«si). Mendoj se do tĂ« mĂ« kuptoni, ndonĂ«se kjo nuk Ă«shtĂ« gjithmonĂ« e drejtĂ«, por nĂ«se ju flet njĂ« njeri me autoritet nĂ« fushĂ«n e tij â keni njĂ« besim shumĂ« mĂ« tĂ« madh te ajo qĂ« thotĂ« ai. PĂ«r shembull, mendoj se do tĂ« besoni mĂ« shumĂ« nĂ« diagnozĂ«n qĂ« ju jep njĂ« mjek, sesa nĂ« atĂ« tĂ« ndonjĂ« njeriu nga turma (qĂ« ka kĂ«rkuar simptomat nĂ« internet).
Robert Martin â i njohur gjithashtu si Uncle Bob (djedhi Bob) â punon nĂ« fushĂ«n e programimit, pĂ«rkatĂ«sisht nĂ« sisteme tĂ« ndryshme (nga shĂ«rbimet web nĂ« sistemet e integruara), qĂ« nga viti 1970. Ai Ă«shtĂ« njĂ« konsultant dhe arkitekt teknik, ka shkruar pĂ«r revista tĂ« ndryshme teknike, Ă«shtĂ« njĂ« programues shumĂ« i pĂ«rvojshĂ«m, dhe njĂ« person qĂ« ka luajtur njĂ« nga rolesht kryesore nĂ« krijimin e principeve tĂ« njohura SOLID (mund tĂ« thuhet se Ă«shtĂ« krijuesi). Gjithashtu, do tĂ« doja tĂ« shtoja se kĂ«tĂ« libĂ«r mĂ« rekomandoi lideri im i ekipit, me mbi 15 vite pĂ«rvojĂ« nĂ« fushĂ«.
Rreth librit
Varësitë
Para se tĂ« lexoja librin, kam lexuar disa artikuj nĂ« tĂ« njĂ«jtĂ«n platformĂ«, ku shfaqej fjala âvarĂ«siâ. ĂfarĂ« do thotĂ« kjo, kush Ă«shtĂ« i varur nga kush, çfarĂ« konkretisht nĂ«nkupton âtĂ« jesh i varurâ, dhe si mund njĂ« klasĂ« tĂ« jetĂ« e varur nga ndonjĂ«?
Dhe kështu, gjatë leximit të librit kam kuptuar dy çështje:
VarĂ«sia â Ă«shtĂ« njĂ« term, qĂ« do tĂ« thotĂ« se njĂ« klasĂ« (komponent, shĂ«rbim) e njeh njĂ« tjetĂ«r klasĂ« (komponent, shĂ«rbim), dhe kjo njohje nĂ« nivelin e kodit pĂ«rcaktohet (tani programuesit e Java, C#, dhe C do tĂ« mĂ« kuptojnĂ«) me njĂ« import tĂ« caktuar tĂ« hapĂ«sirĂ«s emĂ«rore. Ndryshe: keni njĂ« klasĂ« A me hapĂ«sirĂ«n emĂ«rore Default.Classes dhe njĂ« klasĂ« B Another.Classes. Pra, nĂ«se nĂ« kodin burim tĂ« klasĂ«s A ndodhet pĂ«rdorimi i Another.Classes; â kjo do tĂ« thotĂ« se klasa A Ă«shtĂ« e varur nga klasa B.
PĂ«r tĂ« kuptuar nĂ« skemĂ«, ku Ă«shtĂ« klasa e varur, e ku jo â shikoni drejtimin e shigjetĂ«s: nĂ« 1) shigjeta do tĂ« tregojĂ« nga klasa A nĂ« drejtim tĂ« klasĂ«s B. Kjo do tĂ« thotĂ« se klasa B Ă«shtĂ« mĂ« e pavarur se klasa A. Ndryshimet nĂ« klasĂ«n A nuk do t'i sjellin asnjĂ« âdĂ«mâ klasĂ«s B.
SOLID
NjĂ« nga arsyet kryesore, qĂ« mĂ« shtyu tĂ« lexoj kĂ«tĂ« libĂ«r â Ă«shtĂ« shpjegimi i principeve SĐLID nga burimi origjinal, sepse djali Robert i zhvilloi kĂ«to principe dhe mund tĂ« thuhet se falĂ« tij ne dĂ«gjojmĂ« kĂ«tĂ« emĂ«r â SOLID.
PĂ«r ata qĂ« nuk e dinĂ« â kĂ«to parime flasin dhe rekomandojnĂ« qĂ« tĂ« dizajnojnĂ« aplikacionet e tyre sipas 5 rregullave:
S â SRP (Parimi i pĂ«rgjegjĂ«sisĂ« sĂ« vetme)
O â OCP (Parimi i hapur-mbyllur)
L â LSP (Parimi i zĂ«vendĂ«simit tĂ« Liskov)
I â ISP (Parimi i ndarjes sĂ« ndĂ«rfaqeve)
D â DIP (Parimi i inverzimit tĂ« varĂ«sive)
Të gjitha këto parime mund të aplikohen në nivelin e klasave dhe objekteve, në nivelin e moduleve dhe komponentëve dhe në nivelin e lejerve (shërbimeve).
NĂ«se mendoni se Parimi i pĂ«rgjegjĂ«sisĂ« sĂ« vetme â Ă«shtĂ« nĂ« lidhje me atĂ« qĂ« klasa ose moduli duhet tĂ« bĂ«jĂ« vetĂ«m njĂ« gjĂ« â atĂ«herĂ« patjetĂ«r duhet tĂ« lexoni tĂ« paktĂ«n kapitullin mbi SOLID. Sepse ajo pĂ«rkufizim qĂ« u dha mĂ« lart â Ă«shtĂ« njĂ« pasojĂ«, por jo pĂ«rkufizimi i vetĂ« parimit.
Në lidhje me Inverzimin e Varësive
Dua të tërheq vëmendjen në shpjegimin e Parimit të Inverzimit të Varësive (ajo D nga SOLID). Gjatë leximit të librit, kuptova se nuk është vetëm një parim, por gjithashtu një mekanizëm dhe mjet me të cilin mund të ndryshoni drejtimin e varësive tuaja, duke bërë, për shembull, logjikën e biznesit (DOMAIN) të pavarur nga detajet e zbatimit të Shtresës së Qasjes së Të Dhënave (DAL).
Megjithëse vetë parimi përveç të tjerëve në SOLID do të thotë paksa ndryshe nga mekanizmi, vetë mekanizmi përdoret gjatë gjithë librit dhe është një nga metodat kryesore për të inverzuar dhe ndryshuar drejtimin e varësive tuaja, që po ashtu përdoret në DDD.
PĂ«r marrjen e vendimeve arkitektonike
Shumë shpesh në libër do të përmendet parimi për marrjen e vendimeve të rëndësishme arkitektonike: për atë se cilën DB të përdorni, cilin framework të përdorni, cilën bibliotekë të lidhni, se çfarë të përdorni si motor kërkimi etj.
Pra, autori mendon: ju duhet Tà PRISHNI sa më pak vendime të këtij lloji. Sepse kërkesat mund të ndryshojnë, kufizimet në performancë gjithashtu, dhe përbërja e sjelljes ka tendencë të ndryshojë. Në procesin e zhvillimit, një vendim mund të duket më pak efektiv se një tjetër, më pak i rehatshëm se një tjetër. Dhe forza e arkitekturës tuaj do të përcaktojë se sa shpejt dhe pa dhimbje mund të zëvendësoni një teknologji me një tjetër (për këtë flet po ashtu OCP).
PĂ«r shembull, papritur, mund tĂ« vendosni tĂ« pĂ«rdorni MongoDb nĂ« vend tĂ« Postgresql, ose ndonjĂ«herĂ« skedarĂ«, ose tĂ« pĂ«rdorni tĂ« dhĂ«na tĂ« simulueshme, operacionet me tĂ« cilat do tĂ« kryhen nĂ« memorie. Dhe nĂ«n disa kushte â kjo mund tĂ« detyrojĂ« qĂ« tĂ« rinovoni pothuajse tĂ« gjithĂ« logjikĂ«n.
Për të parandaluar që situata të tilla të ndodhin, ne mund të përdorim disa mekanizma që do të vonojnë sa më shumë që të jetë e mundur vendimmarrjen. Një nga këta mekanizma është abstraksioni.
Referencat për DDD
DDD - Domain Driven Design - është një qasje për zhvillimin e shërbimeve me logjikë biznesi komplekse, që është kritike ndaj ndryshimeve, e orientuar për maksimalizimin e kuptimit nga ana e menaxherëve të projekteve (PM, menaxherët e shitjeve etj.), me anëtarët e zakonshëm. Kështu, që çdo anëtar i projektit të ketë një gjuhë të zakonshme, dhe që çdo njeri të mund të kuptojë tjetrin, dhe që të gjithë të mendojnë në një domain me rregulla të njëjta biznesi.
Nëse ju jeni adhurues i DDD, ose dëshironi të jeni, ose nuk kuptoni diçka në lidhje me të, por dëshironi të kuptoni - libri është i detyrueshëm për t'u lexuar, veçanërisht pjesa e dytë e librit.
Këtu autori shpjegon rreth ekzistencës së Rregullit të Varësisë, dhe pse, duke i ndjekur atë - ju do të ndërtoni arkitekturën e duhur të aplikacionit. Pse varësitë duhet të ndjekin drejtimin në komponentët e Politikës së Lartë, pse domain (komponenti i Politikës së Lartë) duhet të jetë tërësisht i pavarur nga infrastruktura dhe si do ta thjeshtoj këtë për ju në shpërndarje dhe zhvillim
Abstraksioni
Daja Rob, gjithashtu, tregon se si detajet e implementimit mund të dëmtojnë sistemin tuaj, dhe të mos lejojnë evoluimin pa dhimbje në të ardhmen.
Mos harroni!
Baza e të dhënave - është një detaj implementimi
Kënaqësitë (Web, Mobile, etj) - detaje implementimi
Kornizat - janë detajet e implementimit
Duhet të abstraktohemi sa më shumë nga të gjitha këto dhe të mos varemi, duke përdorur varësinë e përshkruar më sipër me ndërfaqet dhe abstraksionet, Rregullin e Varësisë dhe mekanizma të tjera
Metodat e ndërtimit të moduleve
Ky seksion më pëlqeu veçanërisht si zhvillues i shërbimeve në ASP .NET CORE. Këtu përshkruhen metodologjitë e ndërtimit të një arkitekture të vetme shërbimi nga komponentët e gatshëm.
Robert përshkroi 4 skema të mundshme të ndarjes së shtresave.
Ai dha të kuptohet pse mekanizmi i përdorur aq shpesh i arkitekturës tre-shtresore: UI (kontrollorët), Shërbimet (Domeni), DAL (Baza e të Dhënave) - është mjaft i keq krahasuar me të tjerët. Kam parë jo shumë projekte, por në çdo mikro-shërbim, për shembull në backend, përdoret e njëjta arkitekturë tre-shtresore.
Po shkurtimisht, shpesh përdoret arkitektura një-komponent-një-shërbim. Në përgjithësi, të dyjat nuk janë të këqija, por ajo ka mjaft disavantazhe, krahasuar, për shembull, me si ndërtuar arkitektura kur përdoret DDD, veçanërisht në shërbime të kritikuara ndaj ndryshimeve dhe të komplikuara.
Në përgjithësi, ky është fundi i kësaj përmbledhje për librin. Librin vetë e pashë shumë të mirë, nuk më ka penduar për çfarë kam lexuar, faleminderit autorit. Ju, të dashur lexues, faleminderit për vëmendjen, mos gjykoni ashpër - ky publikim është i bazuar në përshtypjet nga libri dhe entuziazmin tim personal.
Burimi: habr.com
