Modüler Yazılım Mimarisi: Sınırları Nereden Kesmeli?
Endüstriyel projelerde sürdürülebilir kod tabanı: modül sınırını nereden kesmeli, API sözleşmeleri nasıl versiyonlanır, karar kayıtları ne işe yarar?
Bu Yazıda
Mühendislik yazılımı projelerinde modüler mimari, domain sınırlarını netleştirerek hem geliştirme hızını hem de sahada güvenilirliği artırır. Özellikle CAD/CAM ve otomasyon ürünlerinde “tek dev monolith” yaklaşımı kısa vadede hızlı görünse de orta vadede bakım maliyetini yükseltir.
Prefabrik üretim, roll-form hatları veya SolidWorks otomasyonu gibi alanlarda yazılım modülleri, üretim gerçekliğine göre ayrılmalıdır: geometri işleme, kural doğrulama, çıktı üretimi, lisans ve kullanıcı arayüzü birbirinden bağımsız evrimleşebilmelidir.
Domain bilgisi yazılım sınırını belirler; AI araçları bu sınırlar içinde hızlandırıcı olarak kullanılır.
- Core: Geometri, parametre modeli, kural motoru
- Integration: CAD API, dosya I/O, ERP/MES köprüleri
- Output: Teknik resim, DXF/DWG, üretim verisi
- Platform: Lisans, loglama, yapılandırma, UI
Test ve doğrulama disiplini
Modüler yapı, birim testlerinin anlamlı olmasını sağlar. Kritik modüllerde regresyon setleri — özellikle parametre değişim senaryoları — ürün güvenilirliğinin temelidir.
Pilot → sınırlı kullanıcı → tam roll-out akışı, mühendislik yazılımında özellikle önemlidir. Her aşamada ölçülebilir metrikler (hazırlık süresi, hata oranı, çıktı tutarlılığı) kaydedilmelidir; sayısal iddialar yalnızca bu verilerle desteklenmelidir.
Modülü teknolojiye göre değil, değişim hızına göre kesin. Aynı sebeple aynı anda değişen şeyler bir modülde durur; farklı sebeplerle değişenler ayrılır. CAD/CAM tarafında bu şöyle bir tabloya oturuyor:
| Modül | Ne zaman değişir | Neye bağımlı olmalı |
|---|---|---|
| Geometri çekirdeği | Nadiren — matematik değişmez | Hiçbir şeye |
| Kural motoru | Sık — üretim standardı değiştikçe | Yalnızca geometri çekirdeğine |
| CAD entegrasyonu | CAD sürümü yükseldikçe | Kural motorunun çıktısına |
| Çıktı üreteci | Müşteri/hat talebiyle | Kural motoruna |
| Platform (lisans, log) | Bağımsız | Hiçbir iş modülüne |
Buradaki tek yön kuralı önemli: hiçbir iş modülü platform modülünü çağırmamalı, platform da iş modülünü tanımamalı. Lisans kontrolü geometri kodunun içine sızdığı an, o kodu test etmek için lisans sunucusu gerekir — ve testler yazılmaz.
Modüller arası sınır bir veri sözleşmesidir, fonksiyon imzası değil. Sözleşmeyi açık bir tipte tutun ve o tipi versiyonlayın:
Sözleşmeyi somutlaştıralım. Diyelim kural motoru bir panel üretiyor. CAD katmanının bilmesi gereken tek şey şu birkaç alan: şema sürümü, genişlik, yükseklik, profil tipi ve boşluk listesi. Başka hiçbir şey. Kural motorunun içinde bu değerlerin nasıl hesaplandığı CAD katmanını hiç ilgilendirmez.
Buradaki şema sürümü alanını ilk günden koyun, değeri 1 olarak dursa bile. Sebebi şu: alan eklemek kırıcı bir değişiklik değildir, ama alan kaldırmak ya da anlamını değiştirmek kırıcıdır. Kırıcı bir değişiklik geldiğinde sürümü artırır ve eski sürüm için küçük bir dönüştürücü yazarsınız. Bu, tüm tüketicileri aynı gün güncellemek zorunda kalmaktan çok daha ucuza gelir.
SchemaVersion alanını baştan koyun, ilk sürümde 1 olarak dursun bile. Alan eklemek kırıcı değildir; alan kaldırmak veya anlamını değiştirmek kırıcıdır. Kırıcı değişiklikte sürümü artırıp eski sürüm için bir dönüştürücü yazmak, tüm tüketicileri aynı gün güncellemek zorunda kalmaktan ucuzdur.
Sözleşmeyi dosyaya (JSON/XML) yazılabilir tutun. Diskte okunabilen bir ara format, hata ayıklamada elinizdeki en güçlü araçtır: müşteriden gelen "şu iş çalışmıyor" mesajı, tek bir dosyaya indirgenebilir.
Mühendislik yazılımında en pahalı bilgi kaybı, bir kararın gerekçesinin unutulmasıdır. Altı ay sonra "bu profil hesabı neden böyle?" sorusuna cevap veremeyen ekip, ya kodu olduğu gibi bırakır ya da yanlış düzeltir.
Ağır bir süreç gerekmez. Depo içinde docs/kararlar/ altında, her kararı tek sayfada tutan kısa notlar yeter:
- Bağlam — hangi kısıt bu kararı zorunlu kıldı (hat toleransı, CAD API sınırı, müşteri standardı)
- Karar — ne yapmaya karar verildi
- Sonuç — bunun neyi kolaylaştırdığı, neyi zorlaştırdığı
- Reddedilen alternatifler — ve neden reddedildikleri
Dördüncü madde en değerlisidir; aynı alternatifin bir yıl sonra tekrar önerilmesini engeller.
Test disiplini: hangi modülde ne test edilir
- Geometri çekirdeği — saf birim testleri. Bağımlılığı olmadığı için en ucuz ve en hızlı testler burada; kapsama oranı en yüksek burada olmalı.
- Kural motoru — senaryo testleri. Gerçek üretim vakalarını girdi/beklenen-çıktı çiftleri olarak dondurun; standart değiştiğinde hangi vakaların kaydığını anında görürsünüz.
- CAD entegrasyonu — az sayıda, gerçek CAD oturumuna karşı çalışan duman testi. Pahalıdır, bu yüzden azdır; ama sıfır olmamalı.
- Çıktı üreteci — anlık görüntü (snapshot) testleri. Üretilen DXF'in bayt bayt aynı olması gerekmez, ama katman adları ve ölçüler sabit kalmalı.
AI araçları modüler mimaride belirgin biçimde daha verimli çalışıyor — sebebi basit: sınırı net olan bir modül, modelin bağlam penceresine sığar. Karşılığında iki kural koyuyorum:
- Sınırlar insanda kalır. Modülün ne yapıp ne yapmayacağına, sözleşmenin şekline ve bağımlılık yönüne ben karar veririm. Bu kararlar yanlışsa, hızlı üretilen kod yanlışı hızlı çoğaltır.
- Sözleşme testi olmayan modülde AI kullanılmaz. Üretilen kodu doğrulayacak bir mekanizma yoksa, kazanılan hız doğrudan risk olarak geri döner.
Pratikte en iyi sonucu, geometri çekirdeği gibi girdisi ve çıktısı saf modüllerde alıyorum; en kötü sonucu, CAD API'siyle konuşan ve durum taşıyan katmanlarda.
Pilot → sınırlı kullanıcı → tam roll-out akışında her aşamada aynı üç sayıyı kaydedin: hazırlık süresi, hata oranı, çıktı tutarlılığı. Sayısal iddialar yalnızca bu kayıtla desteklenmeli — "çok hızlandı" cümlesi bir mühendislik iddiası değildir.
Modüler yazılım mimarisi nedir? Bir sistemi, birbirine yalnızca açık sözleşmelerle bağlanan bağımsız parçalara ayırmaktır. Mühendislik yazılımında bu ayrım teknolojiye göre değil, değişim hızına göre yapılır: aynı sebeple aynı anda değişen şeyler bir modülde durur.
Modül sınırını nereden geçirmeliyim? Değişim sebebinden. Geometri çekirdeği nadiren değişir, kural motoru üretim standardı değiştikçe sık değişir, CAD entegrasyonu sürüm yükseldikçe. Farklı sebeplerle değişen kodu aynı modülde tutmak, en yaygın mimari hatadır.
Modüller arası sözleşme nasıl tanımlanır? Fonksiyon imzasıyla değil, açık bir veri tipiyle. O tipe bir şema sürümü alanı ekleyin ve dosyaya yazılabilir (JSON/XML) tutun; diskte okunabilen bir ara format, hata ayıklamada elinizdeki en güçlü araçtır.
Karar kayıtları (ADR) neden gerekli? Mühendislik yazılımında en pahalı bilgi kaybı, bir kararın gerekçesinin unutulmasıdır. Bağlam, karar, sonuç ve reddedilen alternatifleri tek sayfada tutmak yeterlidir; dördüncü madde aynı alternatifin bir yıl sonra tekrar önerilmesini engeller.
Hangi modülde ne test edilmeli? Geometri çekirdeğinde saf birim testleri, kural motorunda gerçek üretim vakalarından dondurulmuş senaryo testleri, CAD entegrasyonunda az sayıda gerçek oturum duman testi, çıktı üretecinde anlık görüntü testleri.
Yapay zeka destekli geliştirme modüler mimaride neden daha verimli? Sınırı net olan bir modül modelin bağlam penceresine sığar. Ancak iki kural şart: sınır kararları insanda kalmalı ve sözleşme testi olmayan bir modülde üretilen kod kullanılmamalıdır.