Çoğu yazılım projesi şu şekilde başlar: hızlıca bir şeyler çalıştıralım, ilerleyen dönemde düzeltiriz. Bu mantık ilk 6-12 ay işe yarar. Sonrasında yazılım bir yük haline gelir; yeni özellik eklemek giderek zorlaşır, küçük bir değişiklik beklenmedik yerleri bozar, hiç kimse sistemin tamamını anlayamaz hale gelir.
Bu kırılma noktası kötü kod yazımından değil, kötü mimari kararlardan kaynaklanır. Ve bunun önlemi modüler tasarımdır.
Monolitik sistem nedir ve nerede sorun çıkarır?
Monolitik sistemde tüm kod tek bir blok olarak çalışır. Satış modülü, muhasebe modülü, raporlama, kullanıcı yönetimi — hepsi birbirine geçmiş halde. Bu yapı küçük ölçekte avantajlıdır çünkü basittir. Ama büyüdükçe:
- Bir yerde yapılan değişiklik başka yerleri etkiler
- Takımlar birbirinin üzerine yazar, çakışmalar artar
- Tüm sistemi yeniden başlatmadan güncelleme yapmak güçleşir
- Test etmek zorlaşır çünkü her şey birbirine bağlı
- Belirli bir parçayı ölçeklendirmek mümkün olmaz, tüm sistem ölçeklenmek zorunda kalır
Modüler mimari ne sağlar?
Modüler mimaride sistem bağımsız parçalara ayrılır. Her modülün kendi sorumluluğu, kendi veri yapısı ve diğer modüllerle iletişim kurduğu tanımlı bir arayüzü (API) vardır.
- Bağımsız geliştirme: CRM modülü geliştirilirken muhasebe modülü etkilenmez
- Bağımsız güncelleme: Bir modülü kapatmadan diğerini güncelleyebilirsiniz
- Seçici ölçeklendirme: Raporlama modülü yoğunsa yalnızca onu büyütürsünüz
- Hata izolasyonu: Bir modülde hata varsa sistem bütünü çökmez
- Ekip otonom çalışır: Her ekip kendi modülüne odaklanır, koordinasyon yükü azalır
Modüler mimari, yazılımın büyürken parçalanmaması için önceden yerleştirilen bir altyapıdır. Sonradan eklenmez — tasarım aşamasında kurulur.
Gerçek dünya örneği: Çok şubeli perakende
Türkiye'de 12 şubesi olan bir perakende firmasıyla çalıştık. Başlangıç sistemleri monolitikti; stok yönetimi, kasa, müşteri sadakat programı ve raporlama tek bir bütündü. Sorun: her şube güncelleme yapıldığında tüm kasaları yeniden başlatmak gerekiyordu. Kasa başında 20 dakika bekleme, çalışan memnuniyetsizliği, müşteri kuyruğu.
Sistemi modüler hale getirdik:
- Kasa modülü çevrimdışı çalışabilir, bağlantı kesilse bile satış devam eder
- Stok modülü bağımsız güncelleniyor, kasaları etkilemiyor
- Sadakat programı ayrı bir modül olarak geliştirilip entegre edildi
- Merkezi raporlama tüm şubeleri gerçek zamanlı topluyor
Güncelleme süresi 20 dakikadan 0'a indi. Şubeler birbirinden bağımsız çalışmaya başladı.
Her firma modüler mimariyle başlamalı mı?
Hayır. Çok küçük ölçekteki firmalar için modüler mimari gereksiz karmaşıklık olabilir. Ama şu durumlarda modüler yapı baştan kurulmalıdır:
- 2 yıl içinde sistemi büyütme planı varsa
- Farklı ekipler aynı sistem üzerinde çalışacaksa
- Sistemin farklı bölümleri farklı hızda değişecekse
- Üçüncü taraf entegrasyonları (API, ödeme, kargo) hayatın parçasıysa
Mimari borç: Modüler olmayan bir yapıyla başlamak, ilerleyen dönemde "tekrar yazma" maliyetine yol açar. Bu maliyet genellikle ilk geliştirme maliyetinin 3-5 katıdır. Erken kararlar burada çok önemli.
Nereden başlamalı?
Yeni bir sistem planlıyorsanız mimari kararları sprint 0'da alın. İş gereksinimlerinizden yola çıkarak sistemin ana sorumluluk alanlarını belirleyin. Bunlar doğal modül sınırlarınız olacaktır.
Mevcut bir sisteminiz varsa ve büyüme planı yapıyorsanız önce bir mimari analiz yapılmalı. Hangi parçalar birbirinden ayrılabilir, hangi bağımlılıklar kırılmalı — bu soruların cevabı yol haritanızı belirler.