મુખ્ય વસ્તુ વિશે સંક્ષિપ્તમાં: ક્લીન આર્કિટેક્ચર, રોબર્ટ સી. માર્ટિન

આ પુસ્તકની મારી છાપ વિશેની વાર્તા હશે, અને કેટલાક ખ્યાલો અને જ્ઞાનની પણ ચર્ચા કરશે જે, આ પુસ્તકને કારણે, શીખ્યા હતા.

સ્થાપત્ય

શું તમે, આ પ્રકાશન વાંચીને, આર્કિટેક્ચર શું છે તે પ્રશ્નનો સ્પષ્ટ જવાબ આપી શકો છો? પ્રોગ્રામિંગ અને ડિઝાઇનના સંદર્ભમાં આર્કિટેક્ચર શું છે? તેણી કઈ ભૂમિકા ભજવે છે? આ શબ્દમાં ઘણી બધી અસ્પષ્ટતાઓ છે. અને બધું સ્પષ્ટ લાગે છે, પરંતુ કોઈક રીતે અમૂર્ત, અને ચોકસાઇ વિના. માર્ટિન માને છે, અને હું તેની સાથે સંમત છું કે એપ્લિકેશનમાં બે ઘટકો છે:

1. વર્તન - કાર્યો અને કાર્યો કે જે પ્રોગ્રામ (ઘટક, સેવા) કરે છે.
2. આર્કિટેક્ચર - આ શબ્દ એપ્લિકેશન બદલવા વિશે વધુ છે.

પરંતુ જો કોઈ એપ્લીકેશન તે કાર્ય કરે છે જે તે ખૂબ જ સારી રીતે કરવા માટે માનવામાં આવે છે, તો તેનો અર્થ એ નથી કે તેની પાસે સારી આર્કિટેક્ચર છે. આર્કિટેક્ચર એપ્લિકેશન વર્તન વિશે નથી. આર્કિટેક્ચર એ પરિવર્તનની સરળતા વિશે છે, આર્કિટેક્ચર એ જમાવટની સરળતા વિશે છે, આર્કિટેક્ચર વિકાસની સ્વતંત્રતા વિશે છે. આર્કિટેક્ચર એ ઝડપ વિશે છે કે જેની સાથે ટીમમાં નવા વ્યક્તિની સમજણ આવે છે

અને આ આર્કિટેક્ચર કેવી રીતે બનાવવું તે અહીં છે, જ્યારે PM અથવા હિતધારકની જરૂરિયાતોમાં થોડો ફેરફાર થાય ત્યારે માથાનો દુખાવો કેવી રીતે છુટકારો મેળવવો: આ તે છે જે પુસ્તક તમને જણાવશે.

લેખકો વિશે

હું આ પુસ્તક વિશે કંઈ કહું તે પહેલાં, હું મારા વિશે થોડું કહેવા માંગુ છું.
આ ક્ષણે હું એક મજબૂત જુનિયર ડેવલપર છું, ASP .NET CORE નો ઉપયોગ કરીને સેવાઓના વિકાસમાં વિશેષતા ધરાવતો છું.

હું હવે એક વર્ષથી એ જ "ગેલેરી" પર કામ કરી રહ્યો છું, અને એવું લાગે છે કે હું થોડું મેનેજ કરી રહ્યો છું

મેં આ પુસ્તક પહેલેથી જ 2 વાર વાંચ્યું છે, અને હું દરેકને તેની ભલામણ કરું છું:

• એમ્બેડ સિસ્ટમ્સના વિકાસકર્તાઓ;
• ફ્રન્ટ-એન્ડ એન્જિનિયર્સ;
• બેક-એન્ડ કામદારો;
• અને devops માટે પણ.

સામાન્ય રીતે, સૉફ્ટવેરના વિકાસ સાથે કોઈપણ રીતે જોડાયેલા દરેક માટે, અમારો મતલબ વિવિધ વેચાણ અને પીએમનો સીધો વિકાસ છે, અમે અહીં ધ્યાનમાં લેતા નથી (જોકે છોકરીઓ શા માટે ક્યારેક 2 વખત ખર્ચ કરે છે તે જાણવું પણ ઉપયોગી થશે. કાર્ય પર વધુ સમય), હું તમને આ પુસ્તક વાંચવાની સલાહ આપું છું.
અને હવે હું દલીલ કરવાનો પ્રયત્ન કરીશ કે મને શા માટે આવું લાગે છે

આ પુસ્તકના લેખક વિશે થોડુંક (કારણ કે મારા માટે લેખકની સત્તા મોટી ભૂમિકા ભજવે છે). મને લાગે છે કે તમે મને સમજી શકશો, જો કે આ હંમેશા સાચું નથી હોતું, પરંતુ જો ક્ષેત્રમાં કોઈ અધિકૃત વ્યક્તિ તમને કંઈક કહે, તો તમે તેણે જે કહ્યું તેના પર તમે વધુ વિશ્વાસ બતાવો છો. ઉદાહરણ તરીકે, મને લાગે છે કે તમે ભીડમાંથી કોઈ વ્યક્તિ (જેણે લક્ષણોને ગૂગલ કર્યું છે) કરતાં ડૉક્ટર તમને આપેલા નિદાનમાં વધુ વિશ્વાસ કરશો.

રોબર્ટ માર્ટિન - ઉર્ફે અંકલ બોબ (અંકલ બોબ) - 1970 થી પ્રોગ્રામિંગ અને વિવિધ સિસ્ટમ્સ (વેબ સેવાઓથી એમ્બેડેડ સિસ્ટમ્સ સુધી) ક્ષેત્રમાં કામ કરી રહ્યા છે. ટેક્નિકલ કન્સલ્ટન્ટ અને આર્કિટેક્ટ છે, વિવિધ ટેકનિકલ સામયિકો માટે લખ્યું છે, પોતે ખૂબ જ અનુભવી પ્રોગ્રામર છે, અને જાણીતા સોલિડ સિદ્ધાંતોના નિર્માણમાં મુખ્ય ભૂમિકા ભજવનાર વ્યક્તિ છે (કોઈ કદાચ સર્જક કહી શકે). ઉપરાંત, હું ઉમેરવા માંગુ છું કે 15+ કાર્ય અનુભવ સાથે મારી ટીમ લીડ દ્વારા મને આ પુસ્તકની ભલામણ કરવામાં આવી હતી

પુસ્તક વિશે

અવલંબન

પુસ્તક વાંચતા પહેલા, મેં હેબ્રે પર ઘણા બધા લેખો વાંચ્યા, જ્યાં "વ્યસન" શબ્દ દેખાયો. તે શું છે, કોણ કોના પર નિર્ભર છે, "આશ્રિત" નો અર્થ શું છે, અને વર્ગ કોઈ વ્યક્તિ પર કેવી રીતે નિર્ભર છે?

અને જેમ જેમ હું પુસ્તક વાંચતો ગયો તેમ તેમ હું બે બાબતો શીખ્યો:

અવલંબન એ એક શબ્દ છે જેનો અર્થ એ થાય છે કે અમુક વર્ગ (ઘટક, સેવા) અમુક અન્ય વર્ગ (ઘટક, સેવા) વિશે જાણે છે અને કોડ સ્તરે આ જ્ઞાન ચોક્કસ નેમસ્પેસ આયાત દ્વારા નક્કી કરવામાં આવે છે (હવે Javaists, Sharpists, Sishniks મને સમજશે) . બીજા શબ્દોમાં કહીએ તો: તમારી પાસે નેમસ્પેસ ડિફોલ્ટ સાથે વર્ગ A છે. વર્ગો અને વર્ગ B અન્ય. વર્ગો. તેથી, જો વર્ગ A ના સ્ત્રોત કોડમાં Other.Classes નો ઉપયોગ કરવામાં આવ્યો હોય; - આનો અર્થ એ છે કે વર્ગ A વર્ગ B પર આધાર રાખે છે.
આકૃતિ પરથી સમજવા માટે કે આશ્રિત વર્ગ ક્યાં છે અને ક્યાં નથી, તીરની દિશા જુઓ: 1) માં તીર વર્ગ A થી વર્ગ B ની દિશામાં નિર્દેશ કરશે. આનો અર્થ એ છે કે વર્ગ B કરતાં વધુ સ્વતંત્ર છે વર્ગ A. અને વર્ગ A માં ફેરફાર, વર્ગ B ને કોઈ "નુકસાન" થશે નહીં

સોલિડ

મારા માટે આ પુસ્તક વાંચવાનું એક મુખ્ય કારણ મૂળ સ્ત્રોતમાંથી સોલિડ સિદ્ધાંતોની સમજૂતી હતી, કારણ કે અંકલ રોબે આ સિદ્ધાંતો વિકસાવ્યા હતા અને, કોઈ કહી શકે છે, તેમના માટે આભાર અમે આ નામ સાંભળીએ છીએ - SOLID.
જેઓ જાણતા નથી તેમના માટે, આ સિદ્ધાંતો બોલે છે અને તમને 5 નિયમો અનુસાર તમારી એપ્લિકેશન ડિઝાઇન કરવાની સલાહ આપે છે:

S - SRP (એક જવાબદારી સિદ્ધાંત)
O - OCP (ખુલ્લા-બંધ સિદ્ધાંત)
L - LSP (લિસ્કોવ અવેજી સિદ્ધાંત)
I - ISP (ઇન્ટરફેસ સેગ્રિગેશન સિદ્ધાંત)
D - DIP (નિર્ભરતા વ્યુત્ક્રમ સિદ્ધાંત)

આ બધા સિદ્ધાંતો વર્ગો અને ઑબ્જેક્ટ્સના સ્તરે, મોડ્યુલો અને ઘટકોના સ્તરે અને રેલ (સેવાઓ) ના સ્તરે લાગુ કરી શકાય છે.

જો તમને લાગતું હોય કે સિંગલ રિસ્પોન્સિબિલિટી સિદ્ધાંતનો અર્થ એ છે કે વર્ગ અથવા મોડ્યુલે માત્ર એક જ કામ કરવું જોઈએ, તો તમારે ચોક્કસપણે સોલિડ વિશેનું ઓછામાં ઓછું પ્રકરણ વાંચવું જોઈએ. ઉપર આપેલ વ્યાખ્યા માટે પરિણામ છે, પરંતુ સિદ્ધાંતની વ્યાખ્યા નથી

અવલંબન વ્યુત્ક્રમ વિશે

હું ડિપેન્ડન્સી ઇન્વર્ઝન પ્રિન્સિપલ (સોલિડમાંથી એક ડી) ની સમજૂતી પર વિશેષ ધ્યાન આપવા માંગુ છું. જેમ જેમ મેં પુસ્તક વાંચ્યું તેમ, મને સમજાયું કે આ માત્ર એક સિદ્ધાંત નથી, તે એક પદ્ધતિ અને સાધન પણ છે જેની મદદથી તમે તમારી નિર્ભરતાની દિશા બદલી શકો છો અને ઉદાહરણ તરીકે, બિઝનેસ લોજિક (DOMAIN) ની વિગતોથી સ્વતંત્ર બનાવી શકો છો. ડેટા એક્સેસ લેયર અમલીકરણ (DAL)

જો કે સિદ્ધાંત પોતે, SOLID માં અન્ય સાથે, મિકેનિઝમથી થોડો અલગ હોવા છતાં, મિકેનિઝમનો ઉપયોગ સમગ્ર પુસ્તકમાં થાય છે, અને આ તમારી નિર્ભરતાની દિશાને ઉલટાવી અને બદલવા માટેની મુખ્ય પદ્ધતિઓમાંની એક છે, જે, માર્ગ દ્વારા, DDD માં વપરાય છે

આર્કિટેક્ચરલ નિર્ણયો લેવા વિશે

ઘણી વાર પુસ્તક મહત્વપૂર્ણ આર્કિટેક્ચરલ નિર્ણયો લેવાના સિદ્ધાંતનો ઉલ્લેખ કરશે: કયા ડેટાબેઝનો ઉપયોગ કરવો, કયા ફ્રેમવર્કનો ઉપયોગ કરવો, કઈ લાઇબ્રેરીનો સમાવેશ કરવો, સર્ચ એન્જિન તરીકે શું વાપરવું વગેરે.

તેથી, લેખક માને છે: તમારે આવા નિર્ણયો શક્ય તેટલા ઓછા લેવા જોઈએ. કારણ કે આવશ્યકતાઓ બદલાઈ શકે છે, પ્રદર્શન પરના નિયંત્રણો પણ, વર્તણૂકીય ઘટક પોતે બદલાય છે. વિકાસ પ્રક્રિયા દરમિયાન, એક ઉકેલ બીજા કરતાં ઓછો અસરકારક, બીજા કરતાં ઓછો અનુકૂળ લાગે છે. અને તમારા આર્કિટેક્ચરની તાકાત નક્કી કરશે કે તમે કેટલી ઝડપથી અને પીડારહિત રીતે એક ટેક્નોલોજીને બીજી ટેક્નોલોજી સાથે બદલી શકો છો (ઓસીપી આ વિશે વાત કરે છે, માર્ગ દ્વારા).

ઉદાહરણ તરીકે, અચાનક, તમે Postgresql ને બદલે MongoDb નો ઉપયોગ કરવાનું નક્કી કરો છો, અથવા સામાન્ય રીતે ફાઇલો, અથવા મોક ડેટાનો ઉપયોગ કરો છો, જે ઓપરેશન્સ મેમરીમાં કરવામાં આવશે. અને અમુક શરતો હેઠળ, આ તમને લગભગ તમામ તર્કને ફરીથી લખવા માટે દબાણ કરી શકે છે.

આવી પરિસ્થિતિઓને ઉદ્ભવતા અટકાવવા માટે, અમે કેટલીક પદ્ધતિઓનો ઉપયોગ કરી શકીએ છીએ જે શક્ય હોય ત્યાં સુધી નિર્ણય લેવાના સમયને પાછળ ધકેલશે. આમાંની એક પદ્ધતિ એબ્સ્ટ્રેક્શન છે.

DDD ની લિંક્સ

DDD - ડોમેન ડ્રિવન ડિઝાઇન - જટિલ વ્યવસાયિક તર્ક સાથે સેવાઓ વિકસાવવા માટેનો અભિગમ, ફેરફારો માટે મહત્વપૂર્ણ, જેનો ઉદ્દેશ્ય સામાન્ય રોવર્સ સાથે પ્રોજેક્ટ મેનેજમેન્ટ પોઝિશન્સ (PMs, સેલ મેનેજર વગેરે) ની મહત્તમ સમજણ મેળવવાનો છે. એટલે કે, જેથી પ્રોજેક્ટના તમામ સભ્યો વચ્ચે સર્વવ્યાપક ભાષા હશે, અને દરેક વ્યક્તિ બીજાને સમજી શકે, અને જેથી દરેક વ્યક્તિ સમાન વ્યવસાયના નિયમો સાથે સમાન ડોમેનમાં વિચારી શકે.

જો તમે DDD ભક્ત છો, અથવા એક બનવા માંગો છો, અથવા તમે તેના વિશે કંઈક સમજી શકતા નથી, પરંતુ તેને સમજવા માંગો છો, તો પુસ્તક વાંચવું આવશ્યક છે, ખાસ કરીને પુસ્તકનો બીજો ભાગ.

અહીં લેખક ડિપેન્ડન્સી રૂલના અસ્તિત્વ વિશે અને તેનું પાલન કરવાથી તમને યોગ્ય એપ્લિકેશન આર્કિટેક્ચર બનાવવામાં કેમ મદદ મળશે તે સમજાવે છે. ડિપેન્ડન્સી ઉચ્ચ નીતિ ઘટકો તરફ કેમ વહેવી જોઈએ, અને શા માટે ડોમેન (ઉચ્ચ નીતિ ઘટક) માળખાગત સુવિધા-સ્વતંત્ર હોવું જોઈએ અને આ તમારા જમાવટ અને વિકાસને કેવી રીતે સરળ બનાવશે

અમૂર્ત

અંકલ રોબ એ પણ વાત કરે છે કે કેવી રીતે અમલીકરણ વિગતો તમારી સિસ્ટમને નુકસાન પહોંચાડી શકે છે અને ભવિષ્યમાં પીડા વિના તેને વિકસિત થવાથી અટકાવે છે.

યાદ રાખો!
ડેટાબેઝ એ અમલીકરણની વિગતો છે
ગ્રાહકો (વેબ, મોબાઇલ, વગેરે) - અમલીકરણ વિગતો
ફ્રેમવર્ક એ અમલીકરણની વિગતો છે

તમારે ઈન્ટરફેસ અને એબ્સ્ટ્રેક્શન્સ, ડિપેન્ડન્સી રૂલ અને અન્ય મિકેનિઝમ્સ સાથે ઉપર વર્ણવેલ ડિપેન્ડન્સી ઈન્વર્ઝનનો ઉપયોગ કરીને આ બધામાંથી શક્ય તેટલું અમૂર્ત કરવાની જરૂર છે અને તેના પર નિર્ભર નથી.

મોડ્યુલો બનાવવા માટેની પદ્ધતિઓ

મને ખાસ કરીને ASP .NET CORE પર સેવાઓના વિકાસકર્તા તરીકે આ વિભાગ ગમ્યો. કારણ કે અહીં આપણે તૈયાર ઘટકોમાંથી એકીકૃત સેવા આર્કિટેક્ચર બનાવવા માટેની પદ્ધતિઓ વિશે વાત કરીએ છીએ.

રોબર્ટે 4 શક્ય સ્તર અલગ કરવાની યોજનાઓ વર્ણવી.

તેમણે સ્પષ્ટ કર્યું કે શા માટે 3-સ્તર આર્કિટેક્ચરની વારંવાર ઉપયોગમાં લેવાતી મિકેનિઝમ: UI (નિયંત્રકો), સેવાઓ (ડોમેન), DAL (ડેટાબેઝ) અન્યની તુલનામાં ખૂબ ખરાબ છે. મેં ઘણા બધા પ્રોજેક્ટ જોયા નથી, પરંતુ દરેક એક, ઉદાહરણ તરીકે પાછળના છેડે માઇક્રો-સર્વિસ, થ્રી-લેયર આર્કિટેક્ચરનો ઉપયોગ કરે છે.

ઉપરાંત, ઘણી વાર, એક-ઘટક-એક-સેવા આર્કિટેક્ચરનો ઉપયોગ થાય છે. સામાન્ય રીતે, તે બંને ખૂબ સારા છે, પરંતુ તેની તુલનામાં તેના ઘણા બધા ગેરફાયદા છે, ઉદાહરણ તરીકે, ડીડીડીનો ઉપયોગ કરતી વખતે આર્કિટેક્ચર કેવી રીતે બનાવવામાં આવે છે, ખાસ કરીને જટિલ સેવાઓ અને જટિલ સેવાઓ સાથે.

કોઈપણ રીતે, આ પુસ્તક સમીક્ષાનો અંત છે. મને પુસ્તક પોતે જ ગમ્યું, મને તે વાંચવાનો અફસોસ નથી, લેખકનો આભાર. તમારા માટે, પ્રિય વાચકો, તમારા ધ્યાન બદલ આભાર, કડક નિર્ણય ન કરો - આ પ્રકાશન પુસ્તકની છાપ અને મારા વ્યક્તિગત ઉત્સાહ પર આધારિત છે

સોર્સ: www.habr.com