[{"data":1,"prerenderedAt":134},["ShallowReactive",2],{"blog-categories":3,"blog-list":59,"blog-recent":127},[4,19,29,39,49],{"blogCategoryId":5,"name":6,"slug":7,"description":8,"icon":9,"color":10,"displayOrder":11,"postCount":11,"parentCategoryId":12,"parentCategoryName":12,"subCategoryCount":13,"isActive":14,"isDeleted":15,"createDate":16,"updatedDate":17,"deletedDate":12,"createdUserId":18,"updatedUserId":18,"deletedUserId":12},"a854d78d-35e0-4b8f-ae0a-eae60b99a703","Yazılım Geliştirme","yazilim-gelistirme","Yazilim ve programlama konulari","i-lucide-code","#3B82F6",1,null,0,true,false,"2026-03-12T12:42:39.8791515","2026-08-06T10:58:03.9907574","ea4ea297-567a-491b-ac52-37db0674498b",{"blogCategoryId":20,"name":21,"slug":22,"description":23,"icon":24,"color":25,"displayOrder":26,"postCount":11,"parentCategoryId":12,"parentCategoryName":12,"subCategoryCount":13,"isActive":14,"isDeleted":15,"createDate":27,"updatedDate":28,"deletedDate":12,"createdUserId":18,"updatedUserId":18,"deletedUserId":12},"9cc3e207-4160-4041-8c62-ef98192ad80f","Yapay Zeka","yapay-zeka","AI, makine ogrenimi ve derin ogrenme konularinda icerikler","i-lucide-brain","#8B5CF6",2,"2026-03-18T10:06:29.9056513","2026-08-20T18:48:46.3507068",{"blogCategoryId":30,"name":31,"slug":32,"description":33,"icon":34,"color":35,"displayOrder":36,"postCount":11,"parentCategoryId":12,"parentCategoryName":12,"subCategoryCount":13,"isActive":14,"isDeleted":15,"createDate":37,"updatedDate":38,"deletedDate":12,"createdUserId":18,"updatedUserId":18,"deletedUserId":12},"c5ccc953-53f1-4dea-b63d-463034d25947","DevOps ve Bulut","devops-bulut","CI/CD, Docker, Kubernetes, Azure, AWS","i-lucide-cloud","#0EA5E9",5,"2026-03-18T10:30:20.151993","2026-08-20T18:48:47.382576",{"blogCategoryId":40,"name":41,"slug":42,"description":43,"icon":44,"color":45,"displayOrder":46,"postCount":11,"parentCategoryId":12,"parentCategoryName":12,"subCategoryCount":13,"isActive":14,"isDeleted":15,"createDate":47,"updatedDate":48,"deletedDate":12,"createdUserId":18,"updatedUserId":18,"deletedUserId":12},"af5290e6-6c74-4a8b-aafc-87d60196e21d","Veritabanı","veritabani","MSSQL, PostgreSQL, MongoDB, Redis","i-lucide-database","#F59E0B",6,"2026-03-18T10:30:20.1665874","2026-08-20T18:48:47.731112",{"blogCategoryId":50,"name":51,"slug":52,"description":53,"icon":54,"color":55,"displayOrder":56,"postCount":11,"parentCategoryId":12,"parentCategoryName":12,"subCategoryCount":13,"isActive":14,"isDeleted":15,"createDate":57,"updatedDate":58,"deletedDate":12,"createdUserId":18,"updatedUserId":18,"deletedUserId":12},"447e7166-6604-4b8f-8454-374f88b6aec4","Kariyer","kariyer","Yazilimci kariyer rehberleri ve ipuclari","i-lucide-briefcase","#A855F7",8,"2026-03-18T10:30:20.1975357","2026-08-20T18:48:48.3880577",{"items":60,"totalCount":36},[61,75,87,100,113],{"blogPostId":62,"title":63,"slug":64,"content":65,"excerpt":66,"featuredImage":67,"metaTitle":68,"metaDescription":69,"metaKeywords":70,"isPublished":14,"publishedAt":71,"viewCount":13,"likeCount":13,"commentCount":13,"readingTime":72,"authorId":18,"authorName":12,"categoryId":20,"categoryName":21,"tags":73,"isActive":14,"isDeleted":15,"createDate":71,"updatedDate":74,"deletedDate":12,"createdUserId":18,"updatedUserId":18,"deletedUserId":12},"4a16e40c-d3ba-4b8d-bbb6-af6302438874","Yapay Zekâyı Kendi Bilgisayarımda Çalıştırmak: Ne Zaman Mantıklı?","yapay-zekayi-kendi-bilgisayarinda-calistirmak","\u003Ch2>Artık teknik bir başarı değil\u003C/h2>\u003Cp>Bir dil modelini kendi bilgisayarımda ilk çalıştırdığımda bunun bir başarı gibi hissettirdiğini hatırlıyorum. Bugün öyle değil; birkaç dakikalık bir kurulum işi.\u003C/p>\u003Cp>Bu yüzden asıl soru “yapabilir miyim” değil, \u003Cstrong>“benim işim için doğru tercih mi”\u003C/strong>. Bu kararın üç ayağı var: gizlilik, maliyet ve kalite. Üçünü aynı anda en üst seviyede almanız mümkün değil.\u003C/p>\u003Ch2>Gizlilik gerçek bir gerekçedir\u003C/h2>\u003Cp>Hasta verisi, müşteri sözleşmesi, personel dosyası — bu tür içerikleri bir dış servise göndermek çoğu kurumda yalnızca tercih meselesi değil, mevzuat meselesidir. Veri kurumun dışına hiç çıkmayacaksa yerel model tartışmasız doğru cevaptır.\u003C/p>\u003Cp>Burada dikkat ettiğim bir ayrıntı var: “veri gitmiyor” demek, sistemin tamamının çevrimdışı olduğu anlamına gelmiyor. Kullandığınız arayüz, eklenti ya da kayıt mekanizması sessizce dışarı bir şey gönderiyorsa gizlilik iddianız çürür. Kurulumdan sonra ağ trafiğine bakmak, benim için standart bir adım hâline geldi.\u003C/p>\u003Ch2>Maliyet: göründüğü kadar basit değil\u003C/h2>\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>Kalem\u003C/th>\u003Cth>Bulut\u003C/th>\u003Cth>Yerel\u003C/th>\u003C/tr>\u003C/thead>\u003Ctbody>\u003Ctr>\u003Ctd>Başlangıç\u003C/td>\u003Ctd>Yok\u003C/td>\u003Ctd>Donanım yatırımı\u003C/td>\u003C/tr>\u003Ctr>\u003Ctd>Kullanım\u003C/td>\u003Ctd>İstek başına ücret\u003C/td>\u003Ctd>Elektrik\u003C/td>\u003C/tr>\u003Ctr>\u003Ctd>Bakım\u003C/td>\u003Ctd>Sağlayıcıda\u003C/td>\u003Ctd>Sizde\u003C/td>\u003C/tr>\u003Ctr>\u003Ctd>Ölçek\u003C/td>\u003Ctd>Anında artar\u003C/td>\u003Ctd>Donanımla sınırlı\u003C/td>\u003C/tr>\u003C/tbody>\u003C/table>\u003Cp>Kâğıt üzerinde yerel model, yoğun kullanımda ucuz görünüyor. Sahada gözden kaçan kalem ise \u003Cstrong>kendi zamanınız\u003C/strong>. Model güncellemek, sürüm uyumsuzluğu çözmek ve performans ayarı yapmak da bir maliyet — ve genellikle hesaba katılmıyor.\u003C/p>\u003Ch2>Kalite tarafında dürüst olmak gerekiyor\u003C/h2>\u003Cp>Kendi bilgisayarımda çalıştırdığım modeller, en büyük bulut modellerinin yaptığı her işi yapmıyor. Uzun ve çok adımlı akıl yürütme isteyen görevlerde fark açık biçimde görülüyor.\u003C/p>\u003Cp>Buna karşılık sınıflandırma, özetleme, biçim dönüştürme ve şablon doldurma gibi işlerde aradaki fark, benim kullanım senaryolarımda pratikte hissedilmiyor. Bu yüzden basit bir kural benimsedim: \u003Cstrong>işi modele değil, modeli işe göre seçiyorum.\u003C/strong>\u003C/p>\u003Ch2>Donanım konusunda öğrendiklerim\u003C/h2>\u003Cp>En çok yanıldığım nokta işlemci gücü sanmamdı; belirleyici olan bellek. Model belleğe sığmıyorsa hız düşüyor, sığıyorsa iş kabul edilebilir sürede bitiyor. Sıkıştırılmış sürümler bu dengeyi belirgin biçimde iyileştiriyor ve çoğu görevde kalite kaybı fark edilmiyor.\u003C/p>\u003Cp>İkinci öğrendiğim şey, en büyük modeli kurmanın çoğu zaman gereksiz olduğu. Küçük ve hızlı bir model, hızlı cevap verdiği için daha çok kullanılıyor; büyük ve yavaş bir model ise kurulup unutuluyor.\u003C/p>\u003Ch2>Bugün nasıl kullanıyorum?\u003C/h2>\u003Cp>İkisini birlikte kullanıyorum. Hassas içerikler ve tekrar eden hacimli işler yerelde; zor akıl yürütme gerektiren, tek seferlik işler bulutta. Bu ayrım kurulduktan sonra “hangisi daha iyi” tartışması benim için kapandı.\u003C/p>\u003Cp>Yerel modeli önerdiğim tek durum var: \u003Cstrong>verinin dışarı çıkmaması gerekiyorsa.\u003C/strong> Diğer her durumda karar, işin türüne bakıyor — ve çoğu zaman ikisi birden doğru cevap oluyor.\u003C/p>\u003Cp>Bu ayrımı kurduktan sonra beklemediğim bir fayda daha çıktı: yerelde çalıştırmak, modelin sınırlarını çok daha iyi öğretiyor. Bulut servisinde her şey hazır geldiği için nerede zorlandığını fark etmiyorsunuz. Kendi makinenizde bağlam sınırını aştığınızda cevabın nasıl bozulduğunu, sıcaklığı yükselttiğinizde metnin nasıl dağıldığını doğrudan görüyorsunuz.\u003C/p>\u003Cp>Bu deneyim, bulut modellerini kullanma biçimimi de değiştirdi. Artık uzun bir belgeyi olduğu gibi yapıştırmak yerine ilgili bölümü seçiyorum; tutarlılık isteyen işlerde ayarları kısıyorum. Yani yerelde öğrendiğim şey, bulutta da işime yaradı.\u003C/p>\u003Cp>Kurumsal tarafta önerim şu: yerel modeli bir “platform projesi” olarak değil, tek bir sorunu çözen küçük bir kurulum olarak başlatın. Bir departmanın tekrar eden bir işini seçin, ölçün, işe yararsa genişletin. Büyük başlayan kurulumların çoğu, kimin hangi işi yapacağı netleşmediği için yarıda kalıyor. \u003Cstrong>Küçük başlayan ve ölçülen kurulumlar ise yayılıyor.\u003C/strong>\u003C/p>\u003Cp>Bir uyarıyla bitireyim: bu alan çok hızlı değişiyor. Bugün doğru olan donanım tavsiyesi altı ay sonra geçerliliğini yitirebiliyor, bugün yetersiz gelen küçük bir model yarın işinizi görebiliyor. Bu yüzden kurulumumu modele sıkı sıkıya bağlamıyorum; modeli değiştirilebilir bir parça olarak tutuyorum.\u003C/p>\u003Cp>Pratikte bu, uygulamalarımın model yerine bir arayüzle konuşması demek. Model değiştiğinde tek bir ayar satırı değişiyor, kodun geri kalanına dokunulmuyor. Hızla değişen bir alanda kendimi güvende hissettiren tek şey bu oldu.\u003C/p>\u003Chr>\u003Cp>\u003Cstrong>Daha fazlası:\u003C/strong> Kendi bilgisayarınızda model çalıştırmayı adım adım gösterdiğim videoyla kurulumu deneyebilirsiniz.\u003C/p>\u003Cp>\u003Ca href='/videos/yerel-yapay-zeka-gizlilik-acik-kaynak-llmi-kendi-bilgisayarinda-calistir'>Videoyu sitemizde izle\u003C/a>  ·  \u003Ca href='https://youtu.be/Y08MjoZyWVw' target='_blank' rel='noopener'>YouTube'da aç\u003C/a>  ·  \u003Ca href='https://www.youtube.com/@BapatiTech?sub_confirmation=1' target='_blank' rel='noopener'>Bapati kanalına abone ol\u003C/a>\u003C/p>","Yerel dil modeli çalıştırmak her zaman doğru tercih değil. Gizlilik, maliyet ve kalite üçgeninde kararı neye göre verdiğimi ve nerede vazgeçtiğimi anlatıyorum.","https://img.youtube.com/vi/nJb6q5btOTI/maxresdefault.jpg","Yapay Zekâyı Kendi Bilgisayarında Çalıştırmak: Ne Zaman Mantıklı, Ne Zaman Değil? - Bapati","Yerel LLM çalıştırmak ne zaman mantıklı? Gizlilik, maliyet ve kalite dengesi, donanım gerçeği ve kendi kurulumumda öğrendiklerim tek yazıda.","yerel LLM, açık kaynak yapay zeka, veri gizliliği, donanım, maliyet","2026-08-06T11:00:23.0462843",3,[],"2026-08-23T13:26:16.1552457",{"blogPostId":76,"title":77,"slug":78,"content":79,"excerpt":80,"featuredImage":81,"metaTitle":77,"metaDescription":82,"metaKeywords":83,"isPublished":14,"publishedAt":84,"viewCount":13,"likeCount":13,"commentCount":13,"readingTime":72,"authorId":18,"authorName":12,"categoryId":40,"categoryName":41,"tags":85,"isActive":14,"isDeleted":15,"createDate":84,"updatedDate":86,"deletedDate":12,"createdUserId":18,"updatedUserId":18,"deletedUserId":12},"514f40cf-ff7e-40bd-972e-ef83853cacda","HBYS Projelerinde Entegrasyonun Görünmeyen Maliyeti","hbys-projelerinde-entegrasyonun-gorunmeyen-maliyeti","\u003Ch2>Geciken hep aynı yer\u003C/h2>\u003Cp>Hastane bilgi yönetim sistemi projelerinde takvimi sarkıtan şey neredeyse hiçbir zaman modüllerin kendisi olmuyor.\u003C/p>\u003Cp>Poliklinik ekranı, yatış süreci, eczane stoğu — bunlar tanımlı işlerdir, süresi kestirilebilir. Projeyi geciktiren yer, o modüllerin dışarıyla konuştuğu noktalardır: devlet servisleri, laboratuvar cihazları, radyoloji sistemleri, muhasebe tarafı.\u003C/p>\u003Cp>Bunu birkaç projede yaşadıktan sonra tahmin yöntemimi değiştirdim: modülleri değil, \u003Cstrong>bağlantı noktalarını\u003C/strong> saymaya başladım.\u003C/p>\u003Ch2>Entegrasyon bir bağlantı değil, bir sözleşmedir\u003C/h2>\u003Cp>Bir servise bağlanmak teknik olarak yarım günlük iştir. Asıl iş, o servisin kurallarını öğrenmektir: hangi alan zorunlu, hangi durumda hata döner, hata dönerse süreç nerede devam eder.\u003C/p>\u003Cp>Bu kuralların çoğu belgede yazmaz. Sahada öğrenilir ve genellikle canlıya geçtikten sonra öğrenilir. Bir alanın belgede “opsiyonel” yazıp pratikte zorunlu olması, benim en sık karşılaştığım sürprizdir.\u003C/p>\u003Cp>İkinci sürpriz zamanlamadır: test ortamı çalışır, canlı ortam farklı davranır. Bu yüzden artık her entegrasyon için takvime \u003Cstrong>canlı ortamda doğrulama\u003C/strong> adı altında ayrı bir kalem yazıyorum.\u003C/p>\u003Ch2>Cihaz entegrasyonları apayrı bir dünya\u003C/h2>\u003Cp>Yazılım-yazılım entegrasyonu tahmin edilebilir. Cihaz entegrasyonu değil. Laboratuvar ve görüntüleme cihazları çoğu zaman kendi yaşlarının teknolojisini konuşur; bazıları seri port, bazıları eski bir dosya paylaşımı, bazıları da hiç belgelenmemiş bir formatla veri üretir.\u003C/p>\u003Cp>Burada karşılaştığım en pahalı durum şuydu: cihaz sonucu üretiyor ama \u003Cstrong>hangi hastaya ait olduğunu\u003C/strong> yazılım tarafının anlayabileceği biçimde vermiyor. Bu tek sorun, birkaç haftalık bir eşleştirme çalışmasına dönüşebiliyor.\u003C/p>\u003Ch2>Görünmeyen maliyet kalemleri\u003C/h2>\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>Kalem\u003C/th>\u003Cth>Neden teklifte görünmez\u003C/th>\u003C/tr>\u003C/thead>\u003Ctbody>\u003Ctr>\u003Ctd>Kural keşfi\u003C/td>\u003Ctd>Belgede yazmayan davranışlar sonradan çıkar\u003C/td>\u003C/tr>\u003Ctr>\u003Ctd>Hata senaryoları\u003C/td>\u003Ctd>Mutlu yol test edilir, hata yolu üretimde bulunur\u003C/td>\u003C/tr>\u003Ctr>\u003Ctd>Karşı taraf beklemesi\u003C/td>\u003Ctd>Yetki, erişim ve test hesabı süreçleri size bağlı değildir\u003C/td>\u003C/tr>\u003Ctr>\u003Ctd>Veri temizliği\u003C/td>\u003Ctd>Eski kayıtların yeni kurala uymaması\u003C/td>\u003C/tr>\u003Ctr>\u003Ctd>Sürüm değişikliği\u003C/td>\u003Ctd>Karşı servis güncellenir, entegrasyon bozulur\u003C/td>\u003C/tr>\u003C/tbody>\u003C/table>\u003Cp>Son satır özellikle önemli: entegrasyon bir kez yazılıp bitmiyor, \u003Cstrong>bakımı olan bir varlık\u003C/strong> hâline geliyor. Projeyi teslim ettiğinizde iş bitmiyor.\u003C/p>\u003Ch2>Teklif verirken sorduğum sorular\u003C/h2>\u003Cp>Artık bir HBYS projesine bakarken önce şu üç soruyu soruyorum: kaç dış sistemle konuşacak, bu sistemlerin belgeleri var mı, ve karşı taraf bir test ortamı sağlayacak mı?\u003C/p>\u003Cp>Üçüncü sorunun cevabı “hayır” ise takvimin üstüne ciddi bir pay ekliyorum. Test ortamı olmayan bir entegrasyon, canlı sistemde denenerek geliştirilir — ve sağlıkta canlı sistemde deneme yapmanın bedeli hep yüksektir.\u003C/p>\u003Cp>Öğrendiğim en net ders şu: \u003Cstrong>bir HBYS projesinin gerçek boyutu, modül listesinde değil entegrasyon listesinde yazar.\u003C/strong>\u003C/p>\u003Cp>Bu üç sorunun yanına dördüncüyü de eklemeyi öğrendim: \u003Cstrong>karşı tarafta bu işi kim yapacak?\u003C/strong> Entegrasyonun teknik zorluğu kadar, karşı kurumdaki muhatabın erişilebilirliği de takvimi belirliyor. Tek bir kişinin bilgisine bağlı bir servis, o kişi izne çıktığında projeyi durdurabiliyor.\u003C/p>\u003Cp>Bir başka öğrendiğim şey, entegrasyonları en başa almak. Ekipler genellikle önce görünen işi — ekranları — yapmak ister; çünkü ilerleme oradan görünür. Ama entegrasyonu sona bırakan her proje, sürprizle sonunda karşılaşıyor ve düzeltmek için zaman kalmıyor. Ben artık en riskli entegrasyonu ilk haftalarda, basit bir denemeyle test ediyorum.\u003C/p>\u003Cp>Bu deneme çoğu zaman tam bir çözüm olmuyor; sadece “bağlanabiliyor muyuz, hangi alanlar geliyor, hata nasıl dönüyor” sorularını cevaplıyor. Bir haftalık bu çalışma, ilerleyen aylarda haftalar kazandırıyor. \u003Cstrong>Riski erken görmek, riski küçültmenin en ucuz yolu.\u003C/strong>\u003C/p>\u003Cp>Bir konuda daha net fikrim var: entegrasyon maliyetini tekliften saklamak, kimseye iyilik etmiyor. Düşük tutulmuş bir kalem, proje ortasında değişiklik talebi olarak geri geliyor ve o noktada hem güven hem takvim zedeleniyor. Kalemi baştan yazmak zor bir konuşma; ortada yaşamak ise çok daha zor.\u003C/p>\u003Cp>Son olarak, entegrasyon işini yapan kişinin sahayı görmesi gerektiğini düşünüyorum. Bir laboratuvar cihazının sonucu nasıl ürettiğini ekranın başında değil, cihazın yanında anlıyorsunuz. Bir hemşirenin hangi alanı neden boş bıraktığını da poliklinikte on dakika durarak öğreniyorsunuz.\u003C/p>\u003Cp>Uzaktan yazılan entegrasyonların çoğu teknik olarak doğru, pratikte kullanışsız oluyor. Sahayı gören biri, belgede yazmayan ama işin yürümesi için kritik olan ayrıntıyı yakalıyor. Bu yüzden bu tür projelerde geçirilen ilk günü hep sahada geçirmeye çalışıyorum.\u003C/p>\u003Chr>\u003Cp>\u003Cstrong>Daha fazlası:\u003C/strong> Sağlıkta veriyle çalışan sistemlerin arkasındaki modelleri anlattığım videoda konunun teknik tarafına giriyorum.\u003C/p>\u003Cp>\u003Ca href='/videos/llm-nasil-calisir-chatgpt-bir-sonraki-kelimeyi-nasil-tahmin-ediyor'>Videoyu sitemizde izle\u003C/a>  ·  \u003Ca href='https://youtu.be/nJb6q5btOTI' target='_blank' rel='noopener'>YouTube'da aç\u003C/a>  ·  \u003Ca href='https://www.youtube.com/@BapatiTech?sub_confirmation=1' target='_blank' rel='noopener'>Bapati kanalına abone ol\u003C/a>\u003C/p>","Sağlık bilişiminde projelerin zamanını modüller değil entegrasyonlar yer. Devlet servisleri ve cihaz bağlantılarında maliyetin nerede saklandığı.","https://bapati.com/images/kapak/hbys-projelerinde-entegrasyonun-gorunmeyen-maliyeti.jpg","HBYS projelerinde takvimi sarkıtan şey modüller değil entegrasyonlardır. Görünmeyen maliyet kalemleri, cihaz bağlantıları ve teklif verirken sorulacaklar.","HBYS, sağlık bilişimi, entegrasyon, proje yönetimi, cihaz entegrasyonu","2026-08-06T11:00:22.9087449",[],"2026-08-23T13:51:59.0185148",{"blogPostId":88,"title":89,"slug":90,"content":91,"excerpt":92,"featuredImage":93,"metaTitle":94,"metaDescription":95,"metaKeywords":96,"isPublished":14,"publishedAt":97,"viewCount":13,"likeCount":13,"commentCount":13,"readingTime":72,"authorId":18,"authorName":12,"categoryId":5,"categoryName":6,"tags":98,"isActive":14,"isDeleted":15,"createDate":97,"updatedDate":99,"deletedDate":12,"createdUserId":18,"updatedUserId":18,"deletedUserId":12},"a14c6105-f2ea-426f-8255-fa2c690de7e2","Clean Architecture'ı Gerçek Projede Uygulamak: Nerede İşe Yarar, Nerede Yük Olur?","clean-architecture-gercek-projede-katmanlar","\u003Ch2>İki zıt cümle, aynı sebep\u003C/h2>\u003Cp>Clean Architecture hakkında en sık duyduğum iki cümle birbirinin tam zıddı: “her projede kullanıyoruz” ve “gereksiz karmaşıklık”. İlginç olan şu — ikisi de aynı sebepten doğru olabiliyor.\u003C/p>\u003Cp>Mimari bir inanç meselesi değil, bir \u003Cstrong>maliyet hesabıdır\u003C/strong>. Katman eklemek bugün vakit kaybettirir, yarın değişiklik yapmayı ucuzlatır. Asıl soru şu: o yarın gerçekten gelecek mi?\u003C/p>\u003Ch2>Katman ne zaman kazandırır?\u003C/h2>\u003Cp>Kendi projelerimde katmanlı yapının kendini ödettiği üç net durum gördüm.\u003C/p>\u003Cp>\u003Cstrong>Veri kaynağının değişme ihtimali varsa.\u003C/strong> Bugün bir veritabanı, yarın kurumun dayattığı başka bir veritabanı. Soyutlama varsa değişiklik tek katmanda kalır; yoksa sorgular projenin her yerine dağılmıştır ve değişiklik projeyi baştan yazmaya dönüşür.\u003C/p>\u003Cp>\u003Cstrong>Aynı iş kuralı birden fazla yerden çağrılıyorsa.\u003C/strong> Bir işlem hem API’den hem zamanlanmış bir görevden hem de içe aktarma ekranından çalışıyorsa, kural tek yerde durmalıdır. Aksi hâlde üç kopyadan biri mutlaka güncellenmeyi unutur.\u003C/p>\u003Cp>\u003Cstrong>Projeye başkaları dokunacaksa.\u003C/strong> Tek kişilik bir projede her şeyin nerede olduğunu bilirsiniz. Üç kişi olduğunda “bu kural nerede” sorusu günde birkaç kez sorulur ve katmanlar bu sorunun cevabı hâline gelir.\u003C/p>\u003Ch2>Ne zaman yük olur?\u003C/h2>\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>Durum\u003C/th>\u003Cth>Neden yük\u003C/th>\u003C/tr>\u003C/thead>\u003Ctbody>\u003Ctr>\u003Ctd>Tek ekranlı iç araç\u003C/td>\u003Ctd>Katman sayısı kadar dosya, tek bir işlem için\u003C/td>\u003C/tr>\u003Ctr>\u003Ctd>Ömrü belli prototip\u003C/td>\u003Ctd>Yarın silinecek koda bakım kolaylığı yatırımı\u003C/td>\u003C/tr>\u003Ctr>\u003Ctd>Sadece CRUD yapan servis\u003C/td>\u003Ctd>İş kuralı yoksa iş katmanı boş bir geçiş noktasıdır\u003C/td>\u003C/tr>\u003Ctr>\u003Ctd>Tek kişilik küçük proje\u003C/td>\u003Ctd>Ekip iletişimi sorunu yoksa kazanç da yok\u003C/td>\u003C/tr>\u003C/tbody>\u003C/table>\u003Cp>Bu tabloda en çok tartışılan satır üçüncüsü. Yalnızca kayıt ekleyip listeleyen bir serviste, isteği alıp aynen aşağı geçiren bir “servis katmanı” yazmak hiçbir şey kazandırmaz. \u003Cstrong>Boş katman, mimari değil bürokrasidir.\u003C/strong>\u003C/p>\u003Ch2>Benim izlediğim orta yol\u003C/h2>\u003Cp>Projeye tam katmanlı başlamıyorum. Başlangıçta iki şeyi ayırıyorum: iş kuralları ve dışarısı. Bu, klasör açmakla değil \u003Cstrong>bağımlılıkların yönünü korumakla\u003C/strong> ilgili — iş kuralları veritabanını bilmez.\u003C/p>\u003Cp>Sonra bekliyorum. Aynı kural ikinci kez başka bir yerden çağrıldığında, ya da veritabanı sorgusu üçüncü kez farklı bir dosyada belirdiğinde, o zaman soyutlamayı ekliyorum. Bu yaklaşımın avantajı şu: soyutlamayı \u003Cstrong>gerçek ihtiyaca göre\u003C/strong> tasarlıyorsunuz, tahmine göre değil.\u003C/p>\u003Cp>Erken eklenen soyutlamaların çoğu yanlış yerden bölünmüş oluyor; sonradan onları düzeltmek, baştan yazmaktan zor.\u003C/p>\u003Ch2>Ölçüt olarak kullandığım tek soru\u003C/h2>\u003Cp>Bir katman eklemeden önce kendime hep aynı soruyu soruyorum: \u003Cstrong>bu katman kaldırılırsa hangi değişiklik zorlaşır?\u003C/strong>\u003C/p>\u003Cp>Cevap somut bir örnekse ekliyorum. “İyi pratik” ya da “herkes böyle yapıyor” cevabı geliyorsa eklemiyorum. Bu tek soru, projelerimdeki gereksiz dosya sayısını gözle görülür biçimde azalttı.\u003C/p>\u003Cp>Bu soruyu sormaya başladıktan sonra fark ettiğim bir şey daha oldu: tartışmaların çoğu aslında mimari hakkında değil, \u003Cstrong>ekip alışkanlıkları\u003C/strong> hakkındaydı. “Katman ekleyelim” diyen kişi çoğu zaman düzen istiyor; “gereksiz” diyen kişi ise hız istiyor. İkisi de haklı olabilir ve mesele hangi ihtiyacın o proje için daha acil olduğuna karar vermekten ibaret.\u003C/p>\u003Cp>Bir de şu var: mimari kararlar geri alınabilir olmalı. Katman eklemek, eklemekten vazgeçmekten kolaydır — çünkü kaldırmak, ona bağlanmış her yeri de değiştirmek demek. Bu asimetri yüzünden geç eklemeyi tercih ediyorum. Yanlış zamanda eklenen bir soyutlamayı geri almanın bedeli, biraz geç eklemenin bedelinden yüksek.\u003C/p>\u003Cp>Son olarak, bu kararların yazıya geçirilmesi gerektiğini düşünüyorum. Projeye altı ay sonra bakan kişi — ki o kişi çoğu zaman yine sizsiniz — neden repository kullanıldığını değil, neden \u003Cem>kullanılmadığını\u003C/em> merak eder. Bir sayfalık kısa bir karar notu, aynı tartışmanın her yıl yeniden yapılmasını engelliyor.\u003C/p>\u003Cp>Bir konuda da fikrimi zamanla değiştirdim: eskiden mimariyi projenin başında verilecek bir karar sanıyordum. Şimdi bunun bir kerelik karar değil, proje boyunca tekrar edilen küçük kararlar dizisi olduğunu düşünüyorum. Proje büyüdükçe ihtiyaç değişiyor ve baştan verilmiş büyük karar, çoğu zaman yeni ihtiyaca uymuyor.\u003C/p>\u003Cp>Pratikte bu şu demek: her yeni özellik, mimariyi yeniden düşünmek için küçük bir fırsat. Kod eklemeden önce “bu, mevcut yapıya sığıyor mu” diye sormak; sığmıyorsa yapıyı zorlamak yerine yapının o kısmını gözden geçirmek. Bu alışkanlık, projeleri büyük yeniden yazımlardan koruyan tek şey oldu benim için.\u003C/p>\u003Chr>\u003Cp>\u003Cstrong>Daha fazlası:\u003C/strong> Katmanların hangi sorunu çözdüğünü tek tek gösterdiğim seride bu kararların gerekçelerini bulabilirsiniz.\u003C/p>\u003Cp>\u003Ca href='/videos/clean-architecture-net-8-sifirdan-master-seri-basliyor-bapativault-bolum-112'>Videoyu sitemizde izle\u003C/a>  ·  \u003Ca href='https://youtu.be/2X2CynYp2BA' target='_blank' rel='noopener'>YouTube'da aç\u003C/a>  ·  \u003Ca href='https://www.youtube.com/@BapatiTech?sub_confirmation=1' target='_blank' rel='noopener'>Bapati kanalına abone ol\u003C/a>\u003C/p>","Clean Architecture her projeye uymaz. Katmanlı yapının gerçekten kazandırdığı yerler ile yalnızca dosya sayısını artırdığı yerleri ayırmanın pratik yolu.","https://bapati.com/images/kapak/clean-architecture-gercek-projede-katmanlar.jpg","Clean Architecture'ı Gerçek Bir Projede Uygulamak: Katmanlar Nerede İşe Yarıyor, Nerede Yük Oluyor? - Bapati","Clean Architecture gerçek projede nerede kazandırır, nerede yük olur? Katman kararını maliyet hesabına oturtmanın ve ortadaki yolu bulmanın pratiği.","Clean Architecture, yazılım mimarisi, katmanlı mimari, .NET, teknik borç","2026-08-06T11:00:22.7653003",[],"2026-08-23T13:51:59.3776236",{"blogPostId":101,"title":102,"slug":103,"content":104,"excerpt":105,"featuredImage":106,"metaTitle":107,"metaDescription":108,"metaKeywords":109,"isPublished":14,"publishedAt":110,"viewCount":13,"likeCount":13,"commentCount":13,"readingTime":72,"authorId":18,"authorName":12,"categoryId":30,"categoryName":31,"tags":111,"isActive":14,"isDeleted":15,"createDate":110,"updatedDate":112,"deletedDate":12,"createdUserId":18,"updatedUserId":18,"deletedUserId":12},"0b6c39a6-fbba-49bd-84ba-84de71adeb12","Active Directory'de OU Tasarımı: Büyüdükçe Çöken Yapıyı Baştan Kurmak","active-directory-ou-tasarimi-buyuyen-sirket","\u003Ch2>Otuz kişiden üç yüz kişiye\u003C/h2>\u003Cp>Bir Active Directory yapısı kurulduğu gün nadiren sorun çıkarır. Sorunlar, şirket otuz kişiden üç yüz kişiye çıktığında başlar.\u003C/p>\u003Cp>Sahada gördüğüm tablo hemen her seferinde aynı: kurulumda kullanıcılar tek bir OU’ya atılmış, departmanlar sonradan klasör mantığıyla eklenmiş, yetkiler ise ihtiyaç doğdukça tek tek verilmiş. Yapı teknik olarak çalışır — ta ki birinin “muhasebeye şu politikayı uygula ama şubeleri hariç tut” demesine kadar.\u003C/p>\u003Cp>O cümle, kötü kurulmuş her OU yapısını tek hamlede açığa çıkarır.\u003C/p>\u003Ch2>OU bir klasör değildir\u003C/h2>\u003Cp>En sık yapılan hata, OU’ları dosya sistemi klasörü gibi düşünmektir. Oysa OU’nun iki gerçek işlevi vardır: \u003Cstrong>grup ilkesi uygulamak\u003C/strong> ve \u003Cstrong>yetki devretmek\u003C/strong>. Başka hiçbir şey için OU açılmaz.\u003C/p>\u003Cp>Bu ayrımı kaçırdığınızda ortaya “organizasyon şemasının kopyası” bir yapı çıkar: şirket şeması neyse OU ağacı odur. Kâğıt üzerinde düzenli görünür, ama şirket yeniden yapılandığında — ki yapılanır — tüm ağacı taşımanız gerekir.\u003C/p>\u003Cp>Benim tercih ettiğim ölçüt şudur: \u003Cstrong>bu OU’ya farklı bir politika uygulanacak mı, ya da yönetimi başka birine devredilecek mi?\u003C/strong> İkisi de hayırsa o OU’ya gerek yoktur.\u003C/p>\u003Ch2>Sahada işe yarayan yapı\u003C/h2>\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>Katman\u003C/th>\u003Cth>İçeriği\u003C/th>\u003Cth>Gerekçesi\u003C/th>\u003C/tr>\u003C/thead>\u003Ctbody>\u003Ctr>\u003Ctd>Nesne türü\u003C/td>\u003Ctd>Kullanıcılar / Bilgisayarlar / Servis hesapları ayrı\u003C/td>\u003Ctd>Politikaların çoğu tür bazında farklıdır\u003C/td>\u003C/tr>\u003Ctr>\u003Ctd>Konum veya birim\u003C/td>\u003Ctd>Merkez, şube, üretim…\u003C/td>\u003Ctd>Yetki devri genellikle bu eksende olur\u003C/td>\u003C/tr>\u003Ctr>\u003Ctd>İstisna\u003C/td>\u003Ctd>Yönetici hesapları, kiosk makineler\u003C/td>\u003Ctd>Farklı politika gerektiren küçük kümeler\u003C/td>\u003C/tr>\u003C/tbody>\u003C/table>\u003Cp>Departman ayrımını ise OU’ya değil \u003Cstrong>gruba\u003C/strong> bırakıyorum. Departman değişikliği çok sık olur; grup üyeliğini değiştirmek saniyeler alır, OU taşımak ise politika ve yetki zincirini bozar.\u003C/p>\u003Ch2>Yetki devri: asıl kazanç burada\u003C/h2>\u003Cp>OU tasarımının en çok karşılığını verdiği yer yetki devridir. Şube sorumlusunun kendi kullanıcılarının parolasını sıfırlayabilmesi ama başka hiçbir şeye dokunamaması — bu, doğru kurulmuş bir OU yapısında birkaç dakikalık iştir.\u003C/p>\u003Cp>Yanlış kurulmuş bir yapıda ise iki kötü seçenekten birine mecbur kalırsınız: ya her parola sıfırlama merkeze gelir, ya da şube sorumlusuna gereğinden geniş yetki verilir. İkincisi çok daha sık tercih ediliyor ve \u003Cstrong>güvenlik olaylarının sessiz kaynağı\u003C/strong> oluyor.\u003C/p>\u003Ch2>Mevcut yapıyı düzeltmek\u003C/h2>\u003Cp>Bozuk bir yapıyı düzeltmenin doğru yolu her şeyi bir hafta sonunda taşımak değil. Benim izlediğim sıra şu: önce mevcut politikaların hangi OU’lara bağlı olduğunu çıkarırım, sonra hangi yetkilerin nerede verildiğini listelerim. Bu iki liste çıkmadan tek bir nesne taşımam.\u003C/p>\u003Cp>Ardından yeni yapıyı boş olarak kurar, politikaları önce test grubuna bağlar ve taşımayı departman departman yaparım. Her adımdan sonra bir gün beklerim; çünkü grup ilkesi sorunları çoğu zaman ertesi sabah, kullanıcılar oturum açtığında görünür.\u003C/p>\u003Cp>Bu iş sıkıcıdır ve kimse fark etmez. \u003Cstrong>Ama fark edilmemesi, doğru yapıldığının kanıtıdır.\u003C/strong>\u003C/p>\u003Cp>Bir noktayı özellikle vurgulamak isterim: bu düzeltme işi, teknik olmaktan çok iletişim işidir. Yapıyı değiştirdiğinizde bazı kullanıcıların masaüstü duvar kâğıdı değişir, bazılarının ağ sürücüsü bir sabah gelmez. Teknik olarak küçük olan bu ayrıntılar, haber verilmediğinde büyük şikâyetlere dönüşür.\u003C/p>\u003Cp>Bu yüzden taşımadan önce ilgili birimlere tek paragraflık bir bilgilendirme gönderiyorum: ne değişecek, ne zaman olacak, bir sorun olursa kime yazılacak. Bu üç cümle, geçiş günündeki telefon trafiğini gözle görülür biçimde azaltıyor.\u003C/p>\u003Cp>Son bir not: yeni yapıyı kurarken adlandırmayı da baştan düzeltmek gerekiyor. Türkçe karakter içeren, boşluklu ve tutarsız adlar taşınan yapıya da birebir taşınırsa, işi ikinci kez yapmış olursunuz. Kısa, tutarlı ve tahmin edilebilir adlar — birkaç yıl sonra o yapıya bakacak kişiye bırakacağınız en iyi miras bu.\u003C/p>\u003Cp>Yapıyı düzelttikten sonra en çok işe yarayan şey, kararların kısa bir belgeye yazılması oldu. Hangi OU’nun neden var olduğu, hangi politikanın nereye bağlandığı ve yetkilerin kime devredildiği tek sayfada duruyor. Bu sayfa olmadığında, birkaç yıl içinde yapı yeniden bozuluyor — çünkü herkes kendi ihtiyacına göre bir OU açıyor.\u003C/p>\u003Cp>Sahada gördüğüm en sağlıklı yapılar, en zekice tasarlanmış olanlar değil; \u003Cstrong>en iyi belgelenmiş\u003C/strong> olanlardı. Basit ama yazılı bir düzen, karmaşık ama kafalarda duran bir düzenden her zaman uzun ömürlü oluyor.\u003C/p>\u003Chr>\u003Cp>\u003Cstrong>Daha fazlası:\u003C/strong> OU ve grup yönetimini uygulamalı gösterdiğim bölümde bu yapının nasıl kurulduğunu adım adım görebilirsiniz.\u003C/p>\u003Cp>\u003Ca href='/videos/active-directory-ou-kullanici-ve-grup-yonetimi-7'>Videoyu sitemizde izle\u003C/a>  ·  \u003Ca href='https://youtu.be/SluTxejI2Xg' target='_blank' rel='noopener'>YouTube'da aç\u003C/a>  ·  \u003Ca href='https://www.youtube.com/@BapatiTech?sub_confirmation=1' target='_blank' rel='noopener'>Bapati kanalına abone ol\u003C/a>\u003C/p>","Çoğu Active Directory yapısı kurulduğunda değil, şirket büyüdüğünde çöker. OU tasarımını yetki ve politika ekseninde kurmanın sahada işe yarayan yolu.","https://img.youtube.com/vi/aFkACN9hrSU/maxresdefault.jpg","Active Directory'de OU Tasarımı: Şirket Büyüdükçe Çöken Yapıyı Baştan Kurmak - Bapati","Active Directory OU tasarımı neden büyüdükçe çöker? Yetki ve politika ekseninde doğru yapı, sık yapılan hatalar ve mevcut yapıyı düzeltme yolu.","Active Directory, OU tasarımı, grup ilkesi, yetki devri, kurumsal ağ","2026-08-06T11:00:22.2254205",[],"2026-08-23T13:26:15.4896698",{"blogPostId":114,"title":115,"slug":116,"content":117,"excerpt":118,"featuredImage":119,"metaTitle":115,"metaDescription":120,"metaKeywords":121,"isPublished":14,"publishedAt":122,"viewCount":13,"likeCount":13,"commentCount":13,"readingTime":123,"authorId":18,"authorName":12,"categoryId":50,"categoryName":51,"tags":124,"isActive":14,"isDeleted":15,"createDate":125,"updatedDate":126,"deletedDate":12,"createdUserId":18,"updatedUserId":18,"deletedUserId":12},"ac52b02f-d30c-4d26-845a-37f36b6faa72","Sistem Yöneticiliğinden Yazılım Mimarlığına: 15 Yılda Öğrendiklerim","sistem-yoneticiliginden-yazilim-mimarligina","\u003Ch2>Gece üçte çalan telefon\u003C/h2>\u003Cp>Kariyerime yazılımcı olarak değil, sahada sistem kurarak başladım. Telsiz-röle sistemlerinden Active Directory mimarilerine, sunucu kurulumlarından kurumsal bilgi sistemlerine uzanan bir yol oldu. Bu süre boyunca aynı anda hem kabloyu çeken hem kodu yazan biri oldum.\u003C/p>\u003Cp>Sistem tarafının bana öğrettiği ilk şey şuydu: \u003Cstrong>bir şeyin çalışması ile güvenilir çalışması arasında dağlar kadar fark var.\u003C/strong> Bunu ders kitabından değil, gece üçte çalan telefondan öğrenirsiniz. Sunucu çöktüğünde açıklama yapacak kişi sizsinizdir ve o an “ama benim makinemde çalışıyordu” diyebileceğiniz kimse yoktur.\u003C/p>\u003Cp>Bu sorumluluk duygusu, sonradan yazılım mimarisine bakışımı kökten değiştirdi.\u003C/p>\u003Ch2>Sistemciler koda nasıl bakar?\u003C/h2>\u003Cp>Sistem tarafından gelen biri, koda çalışıp çalışmadığından çok \u003Cstrong>bozulduğunda ne olacağından\u003C/strong> bakar. Bir geliştirici “bu servis cevap veriyor” der; sistemci “cevap vermezse ne olur, kaç saniye bekler, sonra ne yapar” diye sorar.\u003C/p>\u003Cp>Aradaki farkı en net gördüğüm yer zaman aşımı ayarlarıdır. Kodda hiçbir zaman aşımı tanımlanmamış bir dış çağrı, kâğıt üzerinde son derece temiz görünür. Sahada ise şu olur: karşı taraf yavaşlar, istekler birikir, havuzdaki bağlantılar tükenir ve tek bir yavaş servis, tüm uygulamayı durdurur.\u003C/p>\u003Cp>Bunu bir kez yaşadıktan sonra her dış çağrıya bakışınız değişiyor.\u003C/p>\u003Ch2>Yazılım tarafının bana öğrettikleri\u003C/h2>\u003Cp>Geçişin tersi de doğru. Yazılım tarafı bana sistemcilikte hiç öğrenmediğim bir şeyi öğretti: \u003Cstrong>tekrarlanabilirlik\u003C/strong>.\u003C/p>\u003Cp>Sistem dünyasında bir sunucuyu elle kurarsınız, çalışır ve o kurulumun nasıl yapıldığı çoğu zaman kimsenin aklında kalmaz. Yazılımda ise her şey bir kaynağa yazılıdır; aynı sonucu yeniden üretebilirsiniz. Sürüm kontrolüne alışmak, sistem tarafında yıllarca yaptığım işin ne kadar kırılgan olduğunu bana geriye dönük gösterdi.\u003C/p>\u003Cp>İkinci öğrendiğim şey test etmekti. Sistemcilikte doğrulama genellikle “bir de sen dene” cümlesidir. Yazılımda ise doğrulamayı yazıp otomatikleştirebiliyorsunuz — ve bu, gece üçte çalan telefonu azaltan en somut şey.\u003C/p>\u003Ch2>On beş yılda damıtılan üç ilke\u003C/h2>\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>İlke\u003C/th>\u003Cth>Nereden geliyor\u003C/th>\u003C/tr>\u003C/thead>\u003Ctbody>\u003Ctr>\u003Ctd>Basit olan kazanır\u003C/td>\u003Ctd>Karmaşık kurulumların gece üçte anlaşılmaz olması\u003C/td>\u003C/tr>\u003Ctr>\u003Ctd>Geri dönüş planı olmayan değişiklik yapılmaz\u003C/td>\u003Ctd>Geri alınamayan bir güncellemenin bedelini bir kez ödemek\u003C/td>\u003C/tr>\u003Ctr>\u003Ctd>Görünmeyen sistem yönetilemez\u003C/td>\u003Ctd>Kayıt tutmayan bir sistemde arıza aramanın imkânsızlığı\u003C/td>\u003C/tr>\u003C/tbody>\u003C/table>\u003Cp>Bu üçü bugün kod yazarken de aynen geçerli. Karmaşık bir soyutlama yazdığımda kendime soruyorum: bunu altı ay sonra, sorun çıktığı gece anlayabilecek miyim? Cevap net değilse sadeleştiriyorum.\u003C/p>\u003Ch2>Şimdi ne yapıyorum?\u003C/h2>\u003Cp>Bugün ağırlıklı olarak yazılım tarafındayım; ama sistemciliği bırakmış değilim, çünkü ikisi aynı işin iki yüzü. Yazdığım her uygulamanın bir yerde çalışması, bir yerde yedeklenmesi, bir gün de bozulması gerekiyor.\u003C/p>\u003Cp>Bapati’de anlattığım konuların iki başlıkta toplanmasının nedeni de bu: bir tarafta Active Directory, Exchange ve sistem yönetimi; diğer tarafta .NET, mimari ve kod. İkisini ayrı ayrı öğrenmek mümkün, ama \u003Cstrong>birlikte öğrenildiğinde çok daha anlamlı\u003C/strong> hâle geliyorlar.\u003C/p>\u003Cp>On beş yılda öğrendiğim en kısa ders şu: sistemler kod kadar, kod da sistemler kadar iyidir.\u003C/p>\u003Cp>Bu iki tarafı bir arada taşımanın bir maliyeti de var: hiçbir tarafta “tam uzman” sayılmıyorsunuz. Yazılımcıların çoğu sistem tarafını bilmiyor, sistemcilerin çoğu kod yazmıyor ve siz ikisinin arasında bir yerde duruyorsunuz. Uzun süre bunu bir eksiklik gibi gördüm.\u003C/p>\u003Cp>Zamanla tersinin doğru olduğunu anladım. Bir uygulamanın neden yavaş olduğunu tartışırken masada oturan tek kişi olabiliyorsunuz — çünkü hem sorgunun nasıl çalıştığını hem de o sorgunun gittiği sunucunun diskinin ne yaptığını biliyorsunuz. Bu, kimsenin özel olarak öğretmediği ama sahada en çok işe yarayan beceri.\u003C/p>\u003Cp>Bugün genç birine tavsiyem şu olurdu: hangi taraftan başlarsanız başlayın, öbür tarafı da bir miktar öğrenin. Yazılımcıysanız bir sanal makine kurup ağını kendiniz yapılandırın; sistemciyseniz küçük bir betikle başlayıp gerçekten bir program yazın. İki tarafın sınırında geçirilen zaman, tek tarafta geçirilen zamandan daha çok şey öğretiyor.\u003C/p>\u003Cp>Bir de şu var: sahada geçen yıllar insanı teknolojiye karşı temkinli yapıyor. Yeni bir araç çıktığında ilk sorum artık “ne yapabiliyor” değil, “bozulduğunda ne oluyor ve kim bakıyor”. Bu temkinlilik bazen yavaşlatıyor, ama bugüne kadar beni birkaç kez ciddi hatadan da korudu.\u003C/p>\u003Cp>Aynı temkinlilik yeniliğe kapalı olmak anlamına gelmiyor. Yeni bir teknolojiyi önce kendi ortamımda, bozulduğunda kimseyi etkilemeyecek bir yerde deniyorum. Orada güven verirse işe giriyor. On beş yılda değişmeyen tek alışkanlığım bu oldu.\u003C/p>\u003Chr>\u003Cp>\u003Cstrong>Daha fazlası:\u003C/strong> Sistem tarafında anlattıklarımın uygulamalı hâlini Active Directory serisinde bulabilirsiniz.\u003C/p>\u003Cp>\u003Ca href='/videos/adim-adim-active-directory-kurulumu-dc-dns-dhcp-adc-gc-1'>Videoyu sitemizde izle\u003C/a>  ·  \u003Ca href='https://youtu.be/aFkACN9hrSU' target='_blank' rel='noopener'>YouTube'da aç\u003C/a>  ·  \u003Ca href='https://www.youtube.com/@BapatiTech?sub_confirmation=1' target='_blank' rel='noopener'>Bapati kanalına abone ol\u003C/a>\u003C/p>","Sahada sistem kurarak başlayan bir kariyerin yazılım mimarlığına evrilişi; sistem tarafının koda bakışıma kattıkları ve yıllar içinde damıtılan birkaç sade ilke.","https://bapati.com/images/kapak/sistem-yoneticiliginden-yazilim-mimarligina.jpg","Sistem yöneticiliğinden yazılım mimarlığına giden 15 yıl: sahada öğrendiklerim, iki dünyanın farkı ve bugün kod yazarken hâlâ kullandığım ilkeler.","sistem yöneticiliği, yazılım mimarlığı, kariyer, Active Directory, deneyim","2026-06-17T10:05:00",4,[],"2026-06-17T10:58:08.9488333","2026-08-23T13:51:59.7240961",[128,130,132],{"blogPostId":62,"title":63,"slug":64,"content":65,"excerpt":66,"featuredImage":67,"metaTitle":68,"metaDescription":69,"metaKeywords":70,"isPublished":14,"publishedAt":71,"viewCount":13,"likeCount":13,"commentCount":13,"readingTime":72,"authorId":18,"authorName":12,"categoryId":20,"categoryName":21,"tags":129,"isActive":14,"isDeleted":15,"createDate":71,"updatedDate":74,"deletedDate":12,"createdUserId":18,"updatedUserId":18,"deletedUserId":12},[],{"blogPostId":76,"title":77,"slug":78,"content":79,"excerpt":80,"featuredImage":81,"metaTitle":77,"metaDescription":82,"metaKeywords":83,"isPublished":14,"publishedAt":84,"viewCount":13,"likeCount":13,"commentCount":13,"readingTime":72,"authorId":18,"authorName":12,"categoryId":40,"categoryName":41,"tags":131,"isActive":14,"isDeleted":15,"createDate":84,"updatedDate":86,"deletedDate":12,"createdUserId":18,"updatedUserId":18,"deletedUserId":12},[],{"blogPostId":88,"title":89,"slug":90,"content":91,"excerpt":92,"featuredImage":93,"metaTitle":94,"metaDescription":95,"metaKeywords":96,"isPublished":14,"publishedAt":97,"viewCount":13,"likeCount":13,"commentCount":13,"readingTime":72,"authorId":18,"authorName":12,"categoryId":5,"categoryName":6,"tags":133,"isActive":14,"isDeleted":15,"createDate":97,"updatedDate":99,"deletedDate":12,"createdUserId":18,"updatedUserId":18,"deletedUserId":12},[],1789725834855]