Yazılım Mimarisinde Modüler Yaklaşımlar

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:

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:

// Kural motorunun çıktısı — CAD katmanı yalnızca bunu bilir.
public sealed record PanelSpec(
    int SchemaVersion,          // kırıcı değişiklikte artar
    double WidthMm,
    double HeightMm,
    ProfileType Profile,
    IReadOnlyList<Opening> Openings);

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:

1. Bağlam — hangi kısıt bu kararı zorunlu kıldı (hat toleransı, CAD API sınırı, müşteri standardı)
2. Karar — ne yapmaya karar verildi
3. Sonuç — bunun neyi kolaylaştırdığı, neyi zorlaştırdığı
4. 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.