Giriş:
Bu brifing belgesi, "Head First Software Architecture" kitabından alınan alıntıları ve bölümleri inceleyerek yazılım mimarisinin temel kavramları, boyutları, mimari stilleri ve karar alma süreçleri hakkında bilgi vermektedir. Kitabın özgün öğrenme yaklaşımı ve yazılım mimarisinin karmaşık dünyasına getirdiği pratik bakış açısı vurgulanmaktadır.
Ana Temalar ve Önemli Fikirler:
Yazılım Mimarisinin Gizemi Çözülüyor: Kitap, yazılım mimarisinin temellerini basitleştirerek ve anlaşılır metaforlar kullanarak karmaşıklığını gidermeyi amaçlar. Bina metaforu, yapıyı ve değiştirilmesi zor unsurları vurgulayarak sıkça kullanılır.
Alıntı: "Yazılım mimarisini daha iyi anlamak için mahallenizdeki tipik bir evi düşünün. Evin yapısı, mimarisidir - şekli, kaç odası ve katı olduğu, boyutları vb. gibi şeyler."
Yazılım Mimarisinin Dört Boyutu: Yazılım mimarisini tanımlamak için dört temel boyut gereklidir: mimari özellikler (kalite nitelikleri), mimari kararlar, mantıksal bileşenler ve mimari stiller. Bu boyutların tamamını dikkate almadan yapılan tanımlamalar eksik kalır.
Alıntı: "Yazılım mimarlarının yaptığı hata, mimarilerini tanımlarken bu boyutlardan yalnızca birini ya da ikisini kullanmaktır. 'Mimarimiz mikro hizmetlerdir' ifadesi tek bir boyutu -mimari tarzı- tanımlar ancak çok fazla cevapsız soru bırakır."
Mimari Özellikler (-ilities): Mimari özellikler, sistemin başarısı için kritik öneme sahip, alan dışı tasarım hususlarıdır. Bunlar, performans, ölçeklenebilirlik, güvenlik, esneklik, çeviklik, test edilebilirlik, kullanılabilirlik, hata toleransı, genişletilebilirlik, birlikte çalışabilirlik, fizibilite, sürdürülebilirlik, okunabilirlik ve yasal uyumluluk gibi kalite niteliklerini içerir. Bu özellikler genellikle birbiriyle takasları gerektirir.
Alıntı: "Mimari özellikler şunlardır kritik olan veya sistemin başarısı için önemlidir."
Alıntı: "Uluslararası '-ilities' Hayvanat Bahçesi" başlığı altında geniş bir mimari özellik listesi sunulmaktadır.
Mimari Kararlar: Mimari kararlar, sistemin uzun vadeli veya önemli etkileri olan yapısal yönleri hakkında yapılan seçimlerdir. Bu kararlar, geliştirme ekibine rehberlik eder ve kısıtlamalar olarak işlev görür. Stratejik kararlar daha fazla mimari öneme sahiptir ve önemli takasları içerir.
Alıntı: "Mimari kararlar, sistemin uzun vadeli veya önemli etkileri olan yapısal yönleri hakkında yaptığınız seçimlerdir. Kısıtlamalar olarak, geliştirme ekibinize sistemi planlama ve inşa etme konusunda rehberlik edeceklerdir."
Alıntı: "Kararınız ne kadar stratejik olursa, o kadar mimariyle ilgilidir; ne kadar taktiksel olursa, o kadar tasarımla ilgilidir."
Yazılım Mimarisinin İki Yasası: Her Şey Bir Takas: Yazılım mimarisinde "en iyi uygulamalar" yoktur. Her karar, avantajları ve dezavantajları olan bir takas içerir. Başarılı bir mimar, farklı yaklaşımların takaslarını dikkatle analiz etmeli ve projenin ihtiyaçlarına en uygun olanı seçmelidir.
Alıntı: "Yazılım mimarisi hakkında çabukça öğreneceğiniz bir şey varsa o da en iyi uygulamalara sahip olmadığıdır. Bir karar vermek için her durumu dikkatle analiz etmeniz ve kararın..."
Alıntı: "Geçmişteki başarılar veya gelecek vaatleri ne olursa olsun, unutmayın ki her iyi tarafın bir de kötü tarafı vardır. Cevaplamanız gereken tek soru 'Artılar başarılı bir uygulama gerçekleştirmenize yardımcı olacak mı?' ve 'Eksilerle yaşayabilir misiniz?' olmalıdır."
Mimari Karar Kayıtları (ADR'ler): Mimari kararların ve bunların ardındaki mantığın belgelenmesi (ADR'ler aracılığıyla), kurumsal bilgi birikimi oluşturmak, ekiplerin birbirinden öğrenmesine yardımcı olmak ve gelecekteki karar alma süreçlerini bilgilendirmek için kritik öneme sahiptir. ADR'ler sadece "ne" değil, aynı zamanda "neden" sorusuna da cevap verir.
Alıntı: "ADR'ler, bir sistemin nasıl yapılandırıldığı ve nasıl çalıştığı da dahil olmak üzere, herkesin istediği zaman inceleyebileceği kayıtlardır."
Alıntı: "ADR'ler Yazılım Mimarisinin İkinci Yasasına uymak için önemli araçlardır, çünkü 'ne' ile birlikte 'neden 'i de yakalarlar."
Mantıksal Bileşenler: Mantıksal bileşenler, bir yazılım sisteminin işlevsel yapı taşlarıdır. Her bileşenin iyi tanımlanmış bir rolü ve sorumluluğu olmalıdır. Başlangıç bileşenlerini belirlemek için iş akışı yaklaşımı ve aktör/eylem yaklaşımı gibi yöntemler kullanılır. "Varlık tuzağı" (bileşenleri ana varlıklar etrafında modelleme) gibi kaçınılması gereken yaklaşımlar vardır. Bileşenler arasındaki bağlantı (dependency) ve uyum (cohesion) önemlidir.
Alıntı: "Mantıksal bir bileşenin sistemde her zaman iyi tanımlanmış bir rolü ve sorumluluğu olmalıdır; başka bir deyişle, ne yaptığının net bir tanımı olmalıdır."
Alıntı: "Başlangıçtaki temel bileşenleri belirlemek için size iki yaygın yaklaşım göstereceğiz: iş akışı yaklaşımı ve aktör/eylem yaklaşımı."
Alıntı: "Bir bileşenin rol ve sorumluluk bildirimini veya işlem kümesini analiz ettiğinizde, işlevselliğin birbiriyle yakından ilişkili olup olmadığını kontrol edin. Bu uyum olarak bilinir..."
Mimari Stilleri: Farklı mimari stilleri (katmanlı, modüler monolit, mikro çekirdek, mikro hizmetler, olay güdümlü) sistemin genel şeklini ve yapısını tanımlar. Her stilin kendi felsefesi, avantajları ve dezavantajları vardır ve belirli sorun alanları için daha uygundur. Stiller, kodun teknik veya etki alanına göre nasıl bölümlendirildiği ve sistemin tek bir birim olarak mı yoksa birden fazla birim olarak mı dağıtıldığı temelinde kategorize edilebilir.
Alıntı: "Mimari stiller bir yazılım sisteminin genel şeklini ve yapısını tanımlar her biri kendine özgü bir dizi ö z e l l i ğ e sahiptir."
Alıntı: "Bir stilin felsefesini anlamak, alanınız için doğru stil olup olmadığınıza karar vermenize yardımcı olacaktır."
Öğrenme Yaklaşımı: Kitap, geleneksel teknik kitaplardan farklı olarak, okuyucunun beyninin öğrenme şekline uygun bir yaklaşımla tasarlanmıştır. Sohbet tarzı, görseller, aktiviteler ve tekrarlar, bilgiyi daha etkili bir şekilde akılda tutmaya yardımcı olur.
Alıntı: "Beyniniz yenilik için can atar. Her zaman alışılmadık bir şeyler arar, tarar, bekler."
Alıntı: "Kişiselleştirilmiş, konuşmaya dayalı bir üslup kullandık, çünkü beyniniz bir konuşma içinde olduğunuza inandığında, pasif bir şekilde bir sunumu dinlediğinizi düşündüğünden daha fazla dikkat etmeye ayarlanmıştır."
Önemli Gerçekler/Bilgiler:
Yazılım mimarisi, sistemin başarısı için temel öneme sahiptir.
Mimari özellikler, genellikle gereksinimlerde açıkça belirtilmeyen (örtük) ancak mimarlar tarafından dikkate alınması gereken unsurları içerir (örn. güvenlik).
Yazılım mimarisinde bilinmeyen bilinmeyenler ("unknown unknowns") ortaya çıkabilir ve çeviklik ile iteratif süreçler bunlarla başa çıkmak için önemlidir.
ADR'lerin adlandırılmasında üç basamaklı bir önek ve kısa açıklama önerilir (örn. 042:...).
Mantıksal bileşenlerin rol ve sorumlulukları net olmalıdır; "Yönetici" gibi belirsiz isimlerden kaçınılmalıdır.
Demeter Yasası ("En Az Bilgi İlkesi"), bileşenler arasındaki bağlantıyı azaltmak için diğer bileşenler hakkında sınırlı bilgiye sahip olmayı önerir.
Farklı mimari stilleri farklı sorun alanları için uygunluk gösterir (örn. mikro hizmetler yüksek ölçeklenebilirlik ve çeviklik, mikro çekirdek özelleştirilebilirlik için).
Mimari diyagramlar basit tutulmalı, başlık, anahtar ve tutarlı şekiller/renkler içermelidir.
İş paydaşlarıyla konuşurken teknik detaylar yerine iş değeri (pazara sunma süresi, maliyet, uyumluluk vb.) vurgulanmalıdır.
Sonuç:
"Head First Software Architecture" kitabı, yazılım mimarisinin karmaşık konularını anlaşılır ve ilgi çekici bir şekilde sunarak okuyuculara mimari düşünme becerileri kazandırmayı hedefler. Kitabın vurguladığı temel prensipler arasında mimarinin dört boyutunu anlamak, her kararın bir takas içerdiğini kabul etmek, mimari kararları belgelemek ve farklı mimari stillerinin avantaj ve dezavantajlarını değerlendirmek yer almaktadır. Kitap, pratik örnekler ve egzersizlerle okuyucunun aktif katılımını teşvik ederek bilginin kalıcı olmasını sağlamayı amaçlar.
Bu brifing belgesi, sağlanan kaynaklardan elde edilen ana bilgileri özetlemektedir. Daha derinlemesine bir anlayış için kaynağın tamamının okunması önerilir.