Backend geli\u015ftirme d\u00fcnyas\u0131nda, karma\u015f\u0131k sistemler in\u015fa ederken bazen kendimizi gereksiz bir labirentin i\u00e7inde buluruz. Neden basit olmas\u0131 gereken bir i\u015f ak\u0131\u015f\u0131 bir anda onlarca soyutlama katman\u0131, mikroservis ve veri transfer objesiyle dolup ta\u015far? \u0130\u015fte tam bu noktada, deneyimli web geli\u015ftiricisi Travis McCracken’\u0131n “en \u00e7ok over-engineering yap\u0131lan backend desenleri” hakk\u0131ndaki g\u00f6r\u00fc\u015fleri devreye giriyor. Bu makalede, McCracken’\u0131n merce\u011finden, pop\u00fcler ancak s\u0131kl\u0131kla yanl\u0131\u015f anla\u015f\u0131lan veya gereksiz yere kullan\u0131lan bu desenleri ele alacak, ne zaman faydal\u0131 olduklar\u0131n\u0131 ve ne zaman basitli\u011fi feda etti\u011fimizi anlamaya \u00e7al\u0131\u015faca\u011f\u0131z. Backend projelerinizde daha s\u00fcrd\u00fcr\u00fclebilir, \u00f6l\u00e7eklenebilir ve anla\u015f\u0131l\u0131r mimariler kurmak i\u00e7in pratik bilgiler edinmeye haz\u0131r olun. Amac\u0131m\u0131z, sadece desenleri tan\u0131mak de\u011fil, ayn\u0131 zamanda onlar\u0131 do\u011fru ba\u011flamda, bilin\u00e7li bir \u015fekilde kullanma becerisini kazanmakt\u0131r.<\/p>\n
Yaz\u0131l\u0131m geli\u015ftirme, \u00f6zellikle backend taraf\u0131nda, karma\u015f\u0131kl\u0131\u011f\u0131 y\u00f6netme sanat\u0131d\u0131r. Bir sistemin sadece “\u00e7al\u0131\u015fmas\u0131” yeterli de\u011fildir; ayn\u0131 zamanda s\u00fcrd\u00fcr\u00fclebilir, bak\u0131m\u0131 kolay, \u00f6l\u00e7eklenebilir ve yeni \u00f6zellikler eklenebilir olmas\u0131 gerekir. \u0130\u015fte bu noktada tasar\u0131m desenleri devreye girer. Tasar\u0131m desenleri, yaz\u0131l\u0131m m\u00fchendisli\u011finde s\u0131k\u00e7a kar\u015f\u0131la\u015f\u0131lan problemlere kan\u0131tlanm\u0131\u015f, yeniden kullan\u0131labilir \u00e7\u00f6z\u00fcmler sunan \u015fablonlard\u0131r. Bu desenler, kodun daha organize, anla\u015f\u0131l\u0131r ve uyumlu olmas\u0131n\u0131 sa\u011flayarak ekip \u00e7al\u0131\u015fmas\u0131n\u0131 kolayla\u015ft\u0131r\u0131r ve gelecekteki de\u011fi\u015fiklikler i\u00e7in sa\u011flam bir temel olu\u015fturur.<\/p>\n
\u00d6rne\u011fin, bir veritaban\u0131 ile etkile\u015fim kurarken, veritaban\u0131 ba\u011flant\u0131lar\u0131n\u0131 do\u011frudan her yerde a\u00e7\u0131p kapatmak yerine bir Repository deseni kullanmak, veri eri\u015fim katman\u0131n\u0131 i\u015f mant\u0131\u011f\u0131ndan ay\u0131rarak hem testi kolayla\u015ft\u0131r\u0131r hem de veritaban\u0131 teknolojisi de\u011fi\u015fti\u011finde sadece Repository katman\u0131nda de\u011fi\u015fiklik yapma esnekli\u011fi sunar. Benzer \u015fekilde, sistemdeki nesnelerin olu\u015fturulma \u015feklini kontrol etmek i\u00e7in Factory veya Builder desenleri, nesne ya\u015fam d\u00f6ng\u00fcs\u00fcn\u00fc y\u00f6netmek i\u00e7in Singleton veya Prototype desenleri kullan\u0131l\u0131r. Bu desenler, geli\u015ftiricilerin ortak bir dil konu\u015fmas\u0131n\u0131 sa\u011flayarak kodun okunabilirli\u011fini art\u0131r\u0131r ve yeni ekip \u00fcyelerinin projeye adaptasyon s\u00fcrecini h\u0131zland\u0131r\u0131r. Yani, iyi kullan\u0131ld\u0131klar\u0131nda, tasar\u0131m desenleri bir projenin uzun \u00f6m\u00fcrl\u00fc ve ba\u015far\u0131l\u0131 olmas\u0131n\u0131n anahtarlar\u0131ndan biridir.<\/p>\n
Ancak her g\u00fczel \u015fey gibi, tasar\u0131m desenlerinin de bir “a\u015f\u0131r\u0131 kullan\u0131m” tehlikesi bulunmaktad\u0131r. Bazen geli\u015ftiriciler, problemi tam olarak anlamadan veya \u00e7\u00f6z\u00fcm\u00fcn getirece\u011fi ek karma\u015f\u0131kl\u0131\u011f\u0131 g\u00f6z ard\u0131 ederek pop\u00fcler desenleri uygulamaya y\u00f6nelirler. Bu durum, \u00f6zellikle gen\u00e7 geli\u015ftiriciler aras\u0131nda, “her \u015feyi bir desene uydurma” veya “en son teknolojiyi kullanma” hevesiyle ortaya \u00e7\u0131kabilir. Oysa ki, her desenin belirli bir kullan\u0131m amac\u0131 ve ideal ko\u015fullar\u0131 vard\u0131r. Bir desenin yanl\u0131\u015f ba\u011flamda kullan\u0131lmas\u0131 veya gereksiz yere uygulanmas\u0131, projenin okunabilirli\u011fini ve performans\u0131n\u0131 olumsuz etkileyebilir, hatta beklenen faydan\u0131n tam tersi bir etki yaratabilir. Bu, Travis McCracken’\u0131n s\u0131kl\u0131kla vurgulad\u0131\u011f\u0131 “over-engineering” kavram\u0131n\u0131n temelini olu\u015fturur: basit bir soruna karma\u015f\u0131k bir \u00e7\u00f6z\u00fcm getirmek. Bir sonraki b\u00f6l\u00fcmde, McCracken’\u0131n \u0131\u015f\u0131\u011f\u0131nda, hangi desenlerin bu tuza\u011fa en s\u0131k d\u00fc\u015ft\u00fc\u011f\u00fcn\u00fc ve nedenini daha derinlemesine inceleyece\u011fiz.<\/p>\n
Travis McCracken, backend geli\u015ftiricilerin s\u0131k\u00e7a ba\u015fvurdu\u011fu, ancak \u00e7o\u011fu zaman gereksiz karma\u015f\u0131kl\u0131\u011fa yol a\u00e7an baz\u0131 desenlere dikkat \u00e7ekiyor. Onun temel ele\u015ftirisi, geli\u015ftiricilerin belirli desenleri “moda oldu\u011fu” veya “en iyi uygulama olarak kabul edildi\u011fi” i\u00e7in, projenin ger\u00e7ek ihtiya\u00e7lar\u0131n\u0131 sorgulamadan uygulamas\u0131d\u0131r. Bu durum, projenin ba\u015f\u0131nda h\u0131zl\u0131 geli\u015fimi engelleyebilir, bak\u0131m maliyetlerini art\u0131rabilir ve hatta performans\u0131 d\u00fc\u015f\u00fcrebilir. McCracken’\u0131n s\u0131kl\u0131kla dile getirdi\u011fi ve over-engineering’e yol a\u00e7t\u0131\u011f\u0131n\u0131 belirtti\u011fi ba\u015fl\u0131ca desenler ve yakla\u015f\u0131mlar \u015funlard\u0131r:<\/p>\n
Bu desenlerin hi\u00e7biri “k\u00f6t\u00fc” de\u011fildir; asl\u0131nda her birinin belirli senaryolarda \u00e7ok de\u011ferli faydalar\u0131 vard\u0131r. McCracken’\u0131n ele\u015ftirisi, bu desenlerin “ne zaman ve neden” kullan\u0131laca\u011f\u0131 konusunda yeterince d\u00fc\u015f\u00fcn\u00fclmeden, otomatik bir \u00e7\u00f6z\u00fcm olarak g\u00f6r\u00fclmesinedir. Ger\u00e7ek ba\u015far\u0131, bir desenin potansiyel faydalar\u0131n\u0131 ve getirece\u011fi karma\u015f\u0131kl\u0131\u011f\u0131 dengeleyebilmekten ge\u00e7er. \u015eimdi bu over-engineering tuza\u011f\u0131na d\u00fc\u015fen desenlerden baz\u0131lar\u0131n\u0131 daha detayl\u0131 inceleyelim.<\/p>\n
CQRS, yani Command Query Responsibility Segregation, ad\u0131ndan da anla\u015f\u0131laca\u011f\u0131 \u00fczere, bir uygulamadaki okuma (Query) ve yazma (Command) i\u015flemlerinin sorumluluklar\u0131n\u0131 birbirinden ay\u0131rma prensibine dayan\u0131r. Bu desen, genellikle karma\u015f\u0131k i\u015f alanlar\u0131na sahip, y\u00fcksek performans gerektiren ve farkl\u0131 \u00f6l\u00e7eklenme ihtiya\u00e7lar\u0131 olan uygulamalar i\u00e7in \u00f6nerilir. Teorik olarak, okuma ve yazma i\u015flemlerini ay\u0131rmak, her birinin kendi modelini, kendi veritaban\u0131n\u0131 veya hatta kendi teknoloji y\u0131\u011f\u0131n\u0131n\u0131 kullanmas\u0131na olanak tan\u0131r. Bu da, okuma taraf\u0131n\u0131n \u00f6nbelleklerle h\u0131zland\u0131r\u0131lmas\u0131na veya yazma taraf\u0131n\u0131n olaya dayal\u0131 mimarilerle daha esnek hale getirilmesine olanak tan\u0131r.<\/p>\n
Ancak Travis McCracken’\u0131n da belirtti\u011fi gibi, CQRS her proje i\u00e7in bir “g\u00fcm\u00fc\u015f kur\u015fun” de\u011fildir. Asl\u0131nda, \u00e7o\u011fu standart CRUD uygulamas\u0131 i\u00e7in, CQRS a\u015f\u0131r\u0131ya ka\u00e7an bir m\u00fchendislik y\u00fck\u00fc olu\u015fturur. Bir e-ticaret uygulamas\u0131nda, \u00fcr\u00fcn listeleme (query) ve sipari\u015f verme (command) i\u015flemleri ayr\u0131 ayr\u0131 ele al\u0131nabilir. E\u011fer sipari\u015f verme i\u015flemi \u00e7ok karma\u015f\u0131k i\u015f kurallar\u0131 i\u00e7eriyor ve y\u00fcksek performans gerektiriyorsa, ayn\u0131 zamanda \u00fcr\u00fcn listeleme \u00e7ok s\u0131k yap\u0131l\u0131yor ve h\u0131zl\u0131 yan\u0131t vermesi gerekiyorsa, CQRS mant\u0131kl\u0131 olabilir. Fakat \u00e7o\u011fu durumda, basit bir veritaban\u0131 i\u015flemi, hem okuma hem de yazma i\u00e7in yeterli performans\u0131 ve esnekli\u011fi sa\u011flayacakt\u0131r.<\/p>\n
Vaka Analizi: Gereksiz CQRS Uygulamas\u0131<\/strong><\/p>\n K\u00fc\u00e7\u00fck bir ba\u015flang\u0131\u00e7 firmas\u0131 (startup), “Connectify” ad\u0131nda bir sosyal medya uygulamas\u0131n\u0131 geli\u015ftiriyordu. Uygulaman\u0131n temel \u00f6zellikleri g\u00f6nderi olu\u015fturma, arkada\u015f ekleme, profil g\u00f6r\u00fcnt\u00fcleme ve bildirimlerdi. Geli\u015ftirme ekibi, en yeni mimari trendleri takip etme hevesiyle, hen\u00fcz hi\u00e7bir \u00f6l\u00e7eklenme sorunu ya\u015famamas\u0131na ra\u011fmen, uygulaman\u0131n backend’ini CQRS prensiplerine g\u00f6re tasarlamaya karar verdi. Okuma ve yazma i\u015flemleri i\u00e7in ayr\u0131 veritabanlar\u0131 (bir PostgreSQL ve bir MongoDB), ayr\u0131 API endpoint’leri ve ayr\u0131 kod katmanlar\u0131 olu\u015fturdular. Her bir “command” (\u00f6rne\u011fin, g\u00f6nderi olu\u015fturma) ayr\u0131 bir handler taraf\u0131ndan i\u015fleniyor, her bir “query” (\u00f6rne\u011fin, profil g\u00f6r\u00fcnt\u00fcleme) ayr\u0131 bir sorgu servisi taraf\u0131ndan ele al\u0131n\u0131yordu.<\/p>\n Sonu\u00e7 ne oldu? Projenin ba\u015flang\u0131c\u0131nda, ekip normalde bir hafta s\u00fcrecek bir \u00f6zelli\u011fi \u00fc\u00e7 haftada zor bitiriyordu. Kod taban\u0131, basit bir CRUD i\u015flemi i\u00e7in bile birden fazla dosya, aray\u00fcz ve model i\u00e7eriyordu. Veri tutarl\u0131l\u0131\u011f\u0131 sorunlar\u0131 ba\u015f g\u00f6sterdi \u00e7\u00fcnk\u00fc yazma veritaban\u0131ndaki bir g\u00fcncellemenin okuma veritaban\u0131na yans\u0131mas\u0131 gecikebiliyordu. Geli\u015ftiriciler, “Neden bu kadar karma\u015f\u0131k bir \u015fey yap\u0131yoruz ki?” sorusunu sormaya ba\u015flad\u0131lar. Uygulama hen\u00fcz y\u00fczlerce kullan\u0131c\u0131ya ula\u015fmam\u0131\u015fken, da\u011f\u0131t\u0131k sistemlerin t\u00fcm karma\u015f\u0131kl\u0131\u011f\u0131n\u0131 erken a\u015famada y\u00fcklenmi\u015flerdi. Bu durum, hem geli\u015ftirme h\u0131z\u0131n\u0131 yava\u015flatt\u0131 hem de ekip i\u00e7indeki motivasyonu d\u00fc\u015f\u00fcrd\u00fc. Sonunda, projenin mimarisini daha basit, monolitik bir yap\u0131ya d\u00f6n\u00fc\u015ft\u00fcrmek zorunda kald\u0131lar ve yaln\u0131zca kritik performans ihtiya\u00e7lar\u0131 ortaya \u00e7\u0131kt\u0131\u011f\u0131nda belirli mod\u00fcller i\u00e7in CQRS benzeri \u00e7\u00f6z\u00fcmleri yeniden de\u011ferlendirme karar\u0131 ald\u0131lar.<\/p>\n CQRS’in getirdi\u011fi faydalar\u0131n \u00f6tesinde, olas\u0131 maliyetlerini de g\u00f6z \u00f6n\u00fcnde bulundurmak \u00f6nemlidir. Daha fazla kod, daha fazla soyutlama, daha karma\u015f\u0131k da\u011f\u0131t\u0131m ve bak\u0131m s\u00fcre\u00e7leri anlam\u0131na gelir. Bu da genellikle daha fazla insan kayna\u011f\u0131, daha y\u00fcksek operasyonel giderler ve daha yava\u015f geli\u015ftirme d\u00f6ng\u00fcleri demektir. McCracken’\u0131n bak\u0131\u015f a\u00e7\u0131s\u0131, her zaman en basit ve en etkili \u00e7\u00f6z\u00fcm\u00fc aramay\u0131 te\u015fvik eder. E\u011fer bir problem, daha az bilinen veya “daha az haval\u0131” bir desenle \u00e7\u00f6z\u00fclebiliyorsa, gereksiz karma\u015f\u0131kl\u0131ktan ka\u00e7\u0131nmak her zaman en ak\u0131ll\u0131ca yakla\u015f\u0131md\u0131r. Unutmay\u0131n, iyi bir yaz\u0131l\u0131m mimarisi, m\u00fcmk\u00fcn olan en az karma\u015f\u0131kl\u0131kla i\u015f gereksinimlerini kar\u015f\u0131layabilen mimaridir.<\/p>\n Mikroservis mimarisi, son y\u0131llar\u0131n en pop\u00fcler backend geli\u015ftirme yakla\u015f\u0131mlar\u0131ndan biri haline geldi. Bu mimari, b\u00fcy\u00fck bir monolitik uygulamay\u0131, ba\u011f\u0131ms\u0131z olarak geli\u015ftirilebilen, da\u011f\u0131t\u0131labilen ve \u00f6l\u00e7eklenebilen k\u00fc\u00e7\u00fck, odaklanm\u0131\u015f hizmetlere b\u00f6lme fikrine dayan\u0131r. Her bir mikroservis, genellikle kendi veritaban\u0131na sahip olup, HTTP\/REST veya mesaj kuyruklar\u0131 arac\u0131l\u0131\u011f\u0131yla di\u011fer servislerle ileti\u015fim kurar. Amazon, Netflix gibi devlerin ba\u015far\u0131s\u0131, bir\u00e7ok \u015firketi bu yola itmi\u015ftir. Faydalar\u0131 aras\u0131nda art\u0131r\u0131lm\u0131\u015f \u00f6l\u00e7eklenebilirlik, teknoloji \u00e7e\u015fitlili\u011fi, ba\u011f\u0131ms\u0131z ekiplerin paralel \u00e7al\u0131\u015fabilmesi ve hata yal\u0131t\u0131m\u0131 say\u0131labilir.<\/p>\n Ancak Travis McCracken ve bir\u00e7ok deneyimli geli\u015ftirici, mikroservislerin pop\u00fclaritesinin, onlar\u0131n erken ve gereksiz kullan\u0131m\u0131na yol a\u00e7t\u0131\u011f\u0131 konusunda uyar\u0131yor. Mikroservisler, da\u011f\u0131t\u0131k sistemlerin do\u011fas\u0131 gere\u011fi getirdi\u011fi kendi karma\u015f\u0131kl\u0131k setine sahiptir. Bu karma\u015f\u0131kl\u0131klar \u015funlar\u0131 i\u00e7erir:<\/p>\n Vaka Analizi: Erken Mikroservis Ge\u00e7i\u015finin Bedeli<\/strong><\/p>\n “TaskPilot” adl\u0131 bir proje y\u00f6netimi platformu geli\u015ftiren yeni kurulan bir yaz\u0131l\u0131m \u015firketi, rakiplerinin \u00e7o\u011fu mikroservis kulland\u0131\u011f\u0131 i\u00e7in kendileri de bu yola erken a\u015famada girmeye karar verdiler. Proje hen\u00fcz MVP (Minimum Viable Product) a\u015famas\u0131nda bile de\u011filken, kullan\u0131c\u0131 y\u00f6netimi, g\u00f6rev y\u00f6netimi, bildirimler ve dosya y\u00fckleme gibi mod\u00fclleri ayr\u0131 mikroservislere ay\u0131rd\u0131lar. Her bir servis i\u00e7in ayr\u0131 bir GitHub reposu, ayr\u0131 bir CI\/CD pipeline’\u0131 ve ayr\u0131 bir veritaban\u0131 (farkl\u0131 teknolojilerle) olu\u015fturdular. Ba\u015flang\u0131\u00e7ta 5 ki\u015filik k\u00fc\u00e7\u00fck bir ekip, 4 farkl\u0131 mikroservis \u00fczerinde \u00e7al\u0131\u015f\u0131yordu.<\/p>\n Sonu\u00e7? Geli\u015ftirme s\u00fcreci beklenenden \u00e7ok daha yava\u015f ilerledi. Bir \u00f6zellik, birden fazla serviste de\u011fi\u015fiklik gerektirdi\u011finde, t\u00fcm servislerin senkronize edilmesi, da\u011f\u0131t\u0131lmas\u0131 ve test edilmesi bir kabusa d\u00f6n\u00fc\u015ft\u00fc. “G\u00f6revi tamamla” gibi basit bir i\u015flem, g\u00f6rev servisini g\u00fcncelle, bildirim servisine haber ver, kullan\u0131c\u0131 aray\u00fcz\u00fcn\u00fc g\u00fcncelle gibi zincirleme reaksiyonlara neden oluyordu. Geli\u015ftiriciler, hata ay\u0131klama s\u0131ras\u0131nda log’lar\u0131 farkl\u0131 servislerde aramak, a\u011f sorunlar\u0131n\u0131 \u00e7\u00f6zmek ve da\u011f\u0131t\u0131k i\u015flem hatalar\u0131yla bo\u011fu\u015fmak zorunda kald\u0131. Operasyonel ekip, hen\u00fcz tek bir m\u00fc\u015fterileri yokken bile s\u00fcrekli olarak servislerin ayakta kalmas\u0131n\u0131 sa\u011flamaya \u00e7al\u0131\u015f\u0131yordu.<\/p>\n \u015eirket, pazar rekabetinde geride kalmaya ba\u015flay\u0131nca, bu erken mikroservis karar\u0131n\u0131n kendilerine \u00e7ok pahal\u0131ya mal oldu\u011funu fark etti. Geli\u015ftirme h\u0131z\u0131 d\u00fc\u015fm\u00fc\u015f, maliyetler artm\u0131\u015f ve ekip motivasyonu dibe vurmu\u015ftu. Sonunda, \u00e7o\u011fu servisi tek bir monolitik uygulamada birle\u015ftirme karar\u0131 ald\u0131lar. Bu “tersine m\u00fchendislik” s\u00fcreci de kendi i\u00e7inde b\u00fcy\u00fck bir \u00e7aba gerektirdi. Bug\u00fcn, TaskPilot’\u0131n mimarisi, i\u015f alanlar\u0131 \u00e7ok net ayr\u0131ld\u0131\u011f\u0131nda ve ger\u00e7ek performans darbo\u011fazlar\u0131 ortaya \u00e7\u0131kt\u0131\u011f\u0131nda yava\u015f yava\u015f ve stratejik olarak mikroservislere do\u011fru evrilmeye devam ediyor.<\/p>\n <\/code>\n<\/div>\n Yukar\u0131daki kod \u00f6rneklerinde g\u00f6r\u00fcld\u00fc\u011f\u00fc gibi, monolitik bir yakla\u015f\u0131m i\u00e7indeki bir fonksiyon \u00e7a\u011fr\u0131s\u0131, mikroservis mimarisinde birden fazla HTTP iste\u011fi ve servisler aras\u0131 ileti\u015fim gerektirir. Bu, da\u011f\u0131t\u0131k sistemlerin getirdi\u011fi ek karma\u015f\u0131kl\u0131\u011f\u0131 ve hata y\u00f6netimi ihtiyac\u0131n\u0131 a\u00e7\u0131k\u00e7a g\u00f6sterir. Travis McCracken'\u0131n ana mesaj\u0131 olduk\u00e7a basittir: \"B\u00fcy\u00fckl\u00fc\u011f\u00fcn getirdi\u011fi sorunlar\u0131 \u00e7\u00f6zmek i\u00e7in k\u00fc\u00e7\u00fck sistemler in\u015fa edin, k\u00fc\u00e7\u00fckl\u00fc\u011f\u00fcn getirdi\u011fi sorunlar\u0131 \u00e7\u00f6zmek i\u00e7in karma\u015f\u0131k sistemler de\u011fil.\" Ba\u015flang\u0131\u00e7ta bir monolit ile ba\u015flamak, alan modelleri netle\u015ftik\u00e7e, performans darbo\u011fazlar\u0131 ortaya \u00e7\u0131kt\u0131k\u00e7a ve ekip b\u00fcy\u00fcd\u00fck\u00e7e mod\u00fclleri yava\u015f yava\u015f ayr\u0131 servislere ay\u0131rmak (\"strangler pattern\" gibi), \u00e7o\u011fu zaman \u00e7ok daha g\u00fcvenli ve s\u00fcrd\u00fcr\u00fclebilir bir stratejidir.<\/p>\n Backend geli\u015ftirmenin temel hedeflerinden biri, DRY (Don't Repeat Yourself) prensibini uygulayarak kod tekrar\u0131n\u0131 azaltmak ve ayn\u0131 zamanda mod\u00fcller aras\u0131ndaki ba\u011f\u0131ml\u0131l\u0131klar\u0131 y\u00f6netilebilir d\u00fczeyde tutmakt\u0131r. Ancak McCracken'\u0131n vurgulad\u0131\u011f\u0131 gibi, bu hedeflere ula\u015fmaya \u00e7al\u0131\u015f\u0131rken bazen over-engineering tuza\u011f\u0131na d\u00fc\u015febiliriz. \u00d6rne\u011fin, gereksiz jenerik Repository'ler olu\u015fturarak veya her katman i\u00e7in ayr\u0131 DTO'lar tan\u0131mlayarak kod tekrar\u0131n\u0131 azaltt\u0131\u011f\u0131m\u0131z\u0131 d\u00fc\u015f\u00fcnebiliriz, ancak bu \u00e7o\u011fu zaman daha fazla karma\u015f\u0131kl\u0131\u011fa ve anlams\u0131z soyutlamalara yol a\u00e7ar.<\/p>\n Peki, kod tekrar\u0131n\u0131 azalt\u0131rken ba\u011f\u0131ml\u0131l\u0131klar\u0131 nas\u0131l daha etkili bir \u015fekilde y\u00f6netebiliriz? \u0130\u015fte Travis McCracken'\u0131n da destekleyece\u011fi baz\u0131 pratik yakla\u015f\u0131mlar:<\/p>\n Vaka Analizi: Basitle\u015ftirilmi\u015f API Katman\u0131<\/strong><\/p>\n \"DocuSigner\" adl\u0131 bir belge imzalama platformu, ba\u015flang\u0131\u00e7ta her API endpoint'i i\u00e7in \u00f6zel Request ve Response DTO'lar\u0131 olu\u015fturma e\u011filimindeydi. \u00d6rne\u011fin, bir belgeyi y\u00fcklemek i\u00e7in Travis McCracken'\u0131n prensiplerinden ilham alan ekip lideri, bu yakla\u015f\u0131m\u0131 sorgulamaya ba\u015flad\u0131. Bir vaka analizinin ard\u0131ndan, bir\u00e7ok DTO'nun ger\u00e7ekten gerekli olmad\u0131\u011f\u0131n\u0131 ve i\u015flevsel olarak zaten mevcut olan Domain Model'leri veya daha az say\u0131da, daha genel DTO'lar kullan\u0131larak ayn\u0131 API'nin \u00e7ok daha basit bir \u015fekilde tasarlanabilece\u011fini fark ettiler. \u00d6rne\u011fin, bir belgeyi g\u00fcncelleyen API i\u00e7in, sadece de\u011fi\u015fen alanlar\u0131 i\u00e7eren k\u0131smi bir model veya sadece temel ID ve status bilgisi i\u00e7eren basit bir DTO kullanmak, y\u00fczlerce \u00f6zel DTO olu\u015fturmaktan daha etkiliydi. Ayr\u0131ca, veri do\u011frulamas\u0131n\u0131 (validation) do\u011frudan API istekleri yerine, i\u015f mant\u0131\u011f\u0131 katman\u0131nda veya daha genel bir validasyon servisi arac\u0131l\u0131\u011f\u0131yla yapmak, DTO'lar\u0131n sadece veri ta\u015f\u0131ma i\u015fine odaklanmas\u0131n\u0131 sa\u011flad\u0131.<\/p>\n Bu basitle\u015ftirme, hem geli\u015ftirme h\u0131z\u0131n\u0131 art\u0131rd\u0131 hem de kod taban\u0131n\u0131n bak\u0131m\u0131n\u0131 kolayla\u015ft\u0131rd\u0131. Geli\u015ftiriciler art\u0131k gereksiz d\u00f6n\u00fc\u015ft\u00fcrme kodlar\u0131yla bo\u011fu\u015fmak zorunda kalm\u0131yor, daha az dosya y\u00f6netiyor ve i\u015f mant\u0131\u011f\u0131na daha fazla odaklanabiliyordu. Bu durum, karma\u015f\u0131kl\u0131\u011f\u0131 azalt\u0131rken ayn\u0131 zamanda DRY prensibine uygun, temiz ve s\u00fcrd\u00fcr\u00fclebilir bir kod taban\u0131 olu\u015fturman\u0131n m\u00fcmk\u00fcn oldu\u011funu g\u00f6sterdi.<\/p>\n Kod tekrar\u0131n\u0131 azaltmak ve ba\u011f\u0131ml\u0131l\u0131klar\u0131 y\u00f6netmek, basit ve pragmatik yakla\u015f\u0131mlarla \u00e7ok daha verimli hale getirilebilir. \u00d6nemli olan, problemi do\u011fru tan\u0131mlamak ve \u00e7\u00f6z\u00fcm\u00fc uygulamadan \u00f6nce, bu \u00e7\u00f6z\u00fcm\u00fcn getirece\u011fi faydalar ile ek karma\u015f\u0131kl\u0131\u011f\u0131 dikkatlice tartmakt\u0131r. Tasar\u0131m desenleri g\u00fc\u00e7l\u00fc ara\u00e7lard\u0131r, ancak her ara\u00e7 gibi, do\u011fru zamanda ve do\u011fru \u015fekilde kullan\u0131lmalar\u0131 gerekir.<\/p>\n Travis McCracken'\u0131n g\u00f6r\u00fc\u015fleri, bizi tasar\u0131m desenlerinden tamamen vazge\u00e7meye de\u011fil, onlar\u0131 daha bilin\u00e7li ve stratejik bir \u015fekilde kullanmaya te\u015fvik ediyor. Tasar\u0131m desenleri, yaz\u0131l\u0131m m\u00fchendisli\u011finin temel ta\u015flar\u0131ndan biridir ve do\u011fru ba\u011flamda kullan\u0131ld\u0131\u011f\u0131nda b\u00fcy\u00fck faydalar sa\u011flayabilir. \u00d6nemli olan, bir desenin arkas\u0131ndaki problemi anlamak ve \u00e7\u00f6z\u00fcm\u00fcn projenizin mevcut ihtiya\u00e7lar\u0131na ve gelecekteki potansiyel evrimine uygun olup olmad\u0131\u011f\u0131n\u0131 de\u011ferlendirmektir. Peki, bir tasar\u0131m desenini ne zaman kullanmal\u0131y\u0131z ve bu karar\u0131 nas\u0131l vermeliyiz?<\/p>\n A\u015fa\u011f\u0131daki tablo, baz\u0131 yayg\u0131n desenler i\u00e7in ne zaman kullan\u0131lmalar\u0131 gerekti\u011fine ve ne zaman ka\u00e7\u0131n\u0131lmas\u0131 gerekti\u011fine dair genel bir rehber sunmaktad\u0131r:<\/p>\n \u00d6zetle, tasar\u0131m desenleri, geli\u015ftiricilerin ara\u00e7 kutusundaki g\u00fc\u00e7l\u00fc el aletleridir. Ancak bir tornavidan\u0131n \u00e7ekicin yerini tutmad\u0131\u011f\u0131 gibi, her desenin de kendi \u00f6zel kullan\u0131m alan\u0131 vard\u0131r. Travis McCracken'\u0131n ana mesaj\u0131, pratik bir yakla\u015f\u0131mla, \"do\u011fru arac\u0131 do\u011fru i\u015f i\u00e7in, do\u011fru zamanda\" kullanman\u0131n \u00f6nemini vurgulamaktad\u0131r. En basit \u00e7\u00f6z\u00fcm \u00e7o\u011fu zaman en iyi \u00e7\u00f6z\u00fcmd\u00fcr ve karma\u015f\u0131kl\u0131\u011f\u0131 sadece ger\u00e7ekten ka\u00e7\u0131n\u0131lmaz oldu\u011funda kabul etmeliyiz. Bu yakla\u015f\u0131m, daha sa\u011flam, s\u00fcrd\u00fcr\u00fclebilir ve y\u00f6netilebilir backend sistemleri in\u015fa etmemize yard\u0131mc\u0131 olacakt\u0131r.<\/p>\n Backend geli\u015ftirme yolculu\u011funda, Travis McCracken'\u0131n \u0131\u015f\u0131\u011f\u0131nda yapt\u0131\u011f\u0131m\u0131z bu ke\u015fif, bizlere de\u011ferli dersler sunuyor. G\u00f6rd\u00fck ki, tasar\u0131m desenleri ve mimari yakla\u015f\u0131mlar, yaz\u0131l\u0131m\u0131n karma\u015f\u0131kl\u0131\u011f\u0131n\u0131 y\u00f6netmek i\u00e7in g\u00fc\u00e7l\u00fc ara\u00e7lard\u0131r, ancak bilin\u00e7sizce veya yanl\u0131\u015f ba\u011flamda kullan\u0131ld\u0131\u011f\u0131nda, \"over-engineering\" tuza\u011f\u0131na d\u00fc\u015febilir ve projenin geli\u015fimini yava\u015flat\u0131rken bak\u0131m maliyetlerini art\u0131rabilir. McCracken'\u0131n ele\u015ftirileri, \"moda olan\u0131\" takip etmek yerine, pratik, ihtiyaca y\u00f6nelik ve ba\u011flama duyarl\u0131 bir geli\u015ftirme felsefesi benimsememizin \u00f6nemini vurgulamaktad\u0131r.<\/p>\n \u00d6zellikle CQRS ve mikroservisler gibi g\u00fc\u00e7l\u00fc desenlerin, k\u00fc\u00e7\u00fck veya orta \u00f6l\u00e7ekli projelerde gereksiz yere uygulanmas\u0131, da\u011f\u0131t\u0131k sistemlerin getirdi\u011fi ek y\u00fckle bo\u011fu\u015fmam\u0131za neden olabilir. A\u015f\u0131r\u0131 jenerik Repository'ler ve DTO'lar ise, kod tekrar\u0131n\u0131 azaltma bahanesiyle anlams\u0131z soyutlamalara ve kod y\u0131\u011f\u0131n\u0131na yol a\u00e7abilir. Bu sorunlar\u0131n \u00fcstesinden gelmek i\u00e7in, KISS (Keep It Simple, Stupid) ve YAGNI (You Aren't Gonna Need It) gibi prensiplere ba\u011fl\u0131 kalmak, ba\u011f\u0131ml\u0131l\u0131k enjeksiyonunu ak\u0131ll\u0131ca kullanmak ve her zaman problemi tam olarak anlay\u0131p, \u00e7\u00f6z\u00fcm\u00fcn faydalar\u0131n\u0131 ve maliyetlerini dikkatlice dengelemek esast\u0131r.<\/p>\n Unutmamal\u0131y\u0131z ki, iyi bir yaz\u0131l\u0131m mimarisi, mevcut i\u015f gereksinimlerini en basit ve etkili \u015fekilde kar\u015f\u0131layan mimaridir. Ba\u015flang\u0131\u00e7ta basit bir monolit ile ba\u015flamak ve ancak ger\u00e7ek ihtiya\u00e7lar ortaya \u00e7\u0131kt\u0131\u011f\u0131nda daha karma\u015f\u0131k desenlere veya da\u011f\u0131t\u0131k mimarilere evrilmek (\"monolith-first\" yakla\u015f\u0131m\u0131), \u00e7o\u011fu proje i\u00e7in \u00e7ok daha g\u00fcvenli ve s\u00fcrd\u00fcr\u00fclebilir bir yol haritas\u0131 sunar. Geli\u015ftiriciler olarak, ara\u00e7 setimizdeki desenleri ezbere uygulamak yerine, her birini sorgulamal\u0131, potansiyel etkilerini d\u00fc\u015f\u00fcnmeli ve en \u00f6nemlisi, ekibimiz ve projemizin \u00f6zel ba\u011flam\u0131 i\u00e7in en uygun karar\u0131 vermeliyiz. Bu sayede, sadece \"\u00e7al\u0131\u015fan\" de\u011fil, ayn\u0131 zamanda bak\u0131m\u0131 kolay, \u00f6l\u00e7eklenebilir ve gelece\u011fe haz\u0131r backend sistemleri in\u015fa edebiliriz.<\/p>\n <\/body><\/p>\n","protected":false},"excerpt":{"rendered":"Backend geli\u015ftirme d\u00fcnyas\u0131nda, karma\u015f\u0131k sistemler in\u015fa ederken bazen kendimizi gereksiz bir labirentin i\u00e7inde buluruz. Neden basit olmas\u0131 gereken…","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"csco_page_header_type":"","csco_page_load_nextpost":"","csco_page_subscribe_form":"","csco_page_contact_form":"","footnotes":""},"categories":[1],"tags":[],"class_list":{"0":"post-36060","1":"post","2":"type-post","3":"status-publish","4":"format-standard","6":"category-genel","7":"cs-entry","8":"cs-video-wrap"},"yoast_head":"\nMikroservisler: B\u00fcy\u00fcmeye Y\u00f6nelik Bir \u00c7\u00f6z\u00fcm m\u00fc, Yoksa Erken Bir Karma\u015f\u0131kl\u0131k m\u0131?<\/h3>\n
\n
\n \/\/ Monolitik Yakla\u015f\u0131m: Do\u011frudan Metot \u00c7a\u011fr\u0131s\u0131\n class TaskService {\n constructor(notificationService, userRepository) {\n this.notificationService = notificationService;\n this.userRepository = userRepository;\n }\n\n async completeTask(taskId, userId) {\n const task = await this.taskRepository.findById(taskId);\n if (!task || task.assigneeId !== userId) {\n throw new Error(\"G\u00f6rev bulunamad\u0131 veya yetkiniz yok.\");\n }\n task.status = 'COMPLETED';\n await this.taskRepository.save(task);\n\n const user = await this.userRepository.findById(userId);\n this.notificationService.sendNotification(user.email, G\u00f6reviniz ${task.title} tamamland\u0131!<\/code>);\n console.log(\"G\u00f6rev ba\u015far\u0131yla tamamland\u0131 ve bildirim g\u00f6nderildi.\");\n }\n }\n\n \/\/ Mikroservis Yakla\u015f\u0131m\u0131: HTTP \u00c7a\u011fr\u0131lar\u0131 ve Ayr\u0131 Servisler\n \/\/ (tasks-service)\n class TaskServiceMicro {\n async completeTask(taskId, userId) {\n try {\n const taskUpdateResponse = await fetch(http:\/\/tasks-api\/tasks\/${taskId}\/complete<\/code>, {\n method: 'POST',\n headers: { 'Content-Type': 'application\/json' },\n body: JSON.stringify({ userId })\n });\n const updatedTask = await taskUpdateResponse.json();\n\n \/\/ Bildirim servisine API \u00e7a\u011fr\u0131s\u0131\n await fetch('http:\/\/notifications-api\/send', {\n method: 'POST',\n headers: { 'Content-Type': 'application\/json' },\n body: JSON.stringify({ userId, message: G\u00f6reviniz ${updatedTask.title} tamamland\u0131!<\/code> })\n });\n console.log(\"G\u00f6rev tamamland\u0131 ve bildirim iste\u011fi g\u00f6nderildi.\");\n } catch (error) {\n console.error(\"G\u00f6rev tamamlama veya bildirim g\u00f6nderme hatas\u0131:\", error);\n \/\/ Hata y\u00f6netimi (\u00f6rne\u011fin, telafi edici i\u015flem veya yeniden deneme)\n }\n }\n }\n <\/pre>\nKod Tekrar\u0131n\u0131 Azalt\u0131rken Ba\u011f\u0131ml\u0131l\u0131klar\u0131 Y\u00f6netmek: Daha \u0130yi Yollar Neler?<\/h2>\n
\n
UserRepository<\/code> yerine AuthenticationService<\/code> veya OrderProcessingService<\/code> gibi daha y\u00fcksek seviyeli, i\u015f mant\u0131\u011f\u0131na sahip servisler, kendi i\u00e7lerinde ilgili Repository'leri kullanabilir. Bu, i\u015f mant\u0131\u011f\u0131n\u0131 soyutlar ve kod tekrar\u0131n\u0131 azalt\u0131r \u00e7\u00fcnk\u00fc ayn\u0131 i\u015f kural\u0131 farkl\u0131 yerlerde tekrar yaz\u0131lmaz.<\/li>\nNotificationService<\/code>'in bu s\u0131n\u0131flar\u0131 bir araya getirmesi (kompozisyon) daha iyi bir yakla\u015f\u0131md\u0131r.<\/li>\nUploadDocumentRequest<\/code>, bir belgeyi imzalamak i\u00e7in SignDocumentRequest<\/code> gibi onlarca DTO vard\u0131. \u00c7o\u011fu DTO, sadece documentId<\/code>, userId<\/code>, status<\/code> gibi alanlar\u0131 i\u00e7eriyordu ve bu alanlar Entity'lerden veya di\u011fer DTO'lardan kopyalan\u0131yordu. Bu durum, zamanla projenin kod taban\u0131n\u0131 y\u00fczlerce DTO dosyas\u0131yla doldurdu ve bir de\u011fi\u015fiklik yap\u0131ld\u0131\u011f\u0131nda birden fazla DTO'da ayn\u0131 de\u011fi\u015fikli\u011fi yapma zorunlulu\u011fu getirdi.<\/p>\nTasar\u0131m Desenleri Ne Zaman Kullan\u0131lmal\u0131 ve Nas\u0131l Do\u011fru Karar Verilir?<\/h2>\n
\n
\n\n
\n \nDesen<\/th>\n Ne Zaman Kullan\u0131lmal\u0131?<\/th>\n Ne Zaman Ka\u00e7\u0131n\u0131lmal\u0131?<\/th>\n<\/tr>\n<\/thead>\n \n Repository<\/strong><\/td>\n Veritaban\u0131 etkile\u015fimlerini i\u015f mant\u0131\u011f\u0131ndan ay\u0131rmak, test edilebilirli\u011fi art\u0131rmak.<\/td>\n \u00c7ok basit CRUD i\u015flemleri veya ORM'in sundu\u011fu yetenekler yeterliyse. A\u015f\u0131r\u0131 jeneriklikten ka\u00e7\u0131nmal\u0131.<\/td>\n<\/tr>\n \n CQRS<\/strong><\/td>\n Okuma ve yazma i\u015flemlerinin farkl\u0131 \u00f6l\u00e7eklenebilirlik ve performans gereksinimleri oldu\u011funda. Karma\u015f\u0131k domainler i\u00e7in.<\/td>\n Basit CRUD uygulamalar\u0131, okuma\/yazma y\u00fck\u00fc benzer oldu\u011funda. Erken a\u015fama projeler.<\/td>\n<\/tr>\n \n Mikroservisler<\/strong><\/td>\n B\u00fcy\u00fck, karma\u015f\u0131k, ba\u011f\u0131ms\u0131z ekiplerin \u00e7al\u0131\u015ft\u0131\u011f\u0131, farkl\u0131 teknolojiler gerektiren, y\u00fcksek \u00f6l\u00e7eklenebilirlik ihtiya\u00e7lar\u0131 olan sistemler.<\/td>\n K\u00fc\u00e7\u00fck ve orta \u00f6l\u00e7ekli projeler, alan s\u0131n\u0131rlar\u0131 netle\u015fmemi\u015f projeler. Y\u00fcksek operasyonel maliyetleri g\u00f6ze alamayan ekipler.<\/td>\n<\/tr>\n \n Factory\/Builder<\/strong><\/td>\n Nesne olu\u015fturma mant\u0131\u011f\u0131 karma\u015f\u0131k oldu\u011funda, farkl\u0131 t\u00fcrde nesnelerin dinamik olarak olu\u015fturulmas\u0131 gerekti\u011finde.<\/td>\n Nesne olu\u015fturma basit oldu\u011funda, tek bir constructor yeterliyse.<\/td>\n<\/tr>\n \n DTO'lar<\/strong><\/td>\n Katmanlar aras\u0131nda veri aktar\u0131m\u0131n\u0131 standardize etmek, hassas verileri filtrelemek.<\/td>\n Sadece Entity'leri kopyalayan anlams\u0131z DTO'lar olu\u015fturmak. Her katman i\u00e7in ayr\u0131 DTO tak\u0131nt\u0131s\u0131.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Sonu\u00e7: Daha Sa\u011flam ve S\u00fcrd\u00fcr\u00fclebilir Backend Sistemleri \u0130n\u015fa Etmek<\/h2>\n
S\u0131k\u00e7a Sorulan Sorular<\/h3>\n
\n
\n