Blog
Mert Özen'in yazılım geliştirme, backend, frontend ve DevOps üzerine blog yazıları.
Architecture Decision Nedir? Architecturally Significant Kararları Tanımak
Bir karar geri alması pahalıysa, birden fazla module'ü ya da sistem sınırını etkiliyorsa veya öncelikli bir quality attribute senaryosunu oynatıyorsa mimaridir ve kaydı hak eder. Bookstore'un ilk aylarındaki on kararı bu üç ölçütle C#'ta sınıflandırıyor; hangisinin ADR, hangisinin design doc, hangisinin PR açıklaması hak ettiğini, kararın sahibini ve kayıtsız kararların bedelini konuşuyoruz.
ADR Yazmak: Nygard Şablonu, MADR 4.0 ve Y-Statement ile Karar Kaydı
İyi bir ADR yalnız kararı değil, hangi soruya cevap verdiğini, hangi seçeneklere karşı verildiğini, kabul edilen bedeli ve ne zaman yeniden açılacağını yazar ve karar verildikten sonra değiştirilmez. Nygard'ın beş bölümlü şablonu, MADR 4.0.0'ın bölümleri ve front matter'ı, reddedilmiş bir karar kaydı, Y-statement, status yaşam döngüsü ve immutability kuralını PR'da zorlayan gerçek bir script.
Trade-off Analizi: Seçenekleri Senaryolarla Karşılaştırmak, Sensitivity ve Trade-off Point'ler
Seçenekleri birbirleriyle değil, öncelikli quality attribute senaryolarına karşı ve mümkünse bir spike'ın ölçümleriyle karşılaştırırsın; ATAM'ın sensitivity point, trade-off point ve risk kavramları kararın nerede kırılgan olduğunu gösterir. Bookstore kataloğu için cache yok, HybridCache ve Redis seçenekleri gerçek bir spike'la tartılıyor: p95 neden değişmedi, L2 eski fiyatı neden çözmedi ve weighted decision matrix neden yanıltıyor.
RFC ve Design Doc: Büyük Kararı Yazıyla Tartışmak
Çözümü belirsiz ve birden fazla ekibi etkileyen bir karar önce bir design doc'ta, gerekirse kuralları yazılı bir RFC süreciyle tartışılır; sonuç ise ayrı ve değişmez bir ADR olarak kaydedilir. Bookstore'un sipariş servisine outbox eklemek için yazılmış iki sayfalık design doc üzerinden Context and Scope, ölçülebilir Goals, gerçek Non-Goals, Alternatives Considered, cross-cutting concerns, yaşam döngüsü ve RFC'nin yorum süresi.
Mimariyi Belgelemek: arc42, Docs as Code ve C4 Diyagramlarını ADR'larla Yaşatmak
Mimariyi yaşayan bir belge yapmak için arc42 yapı, C4 view'ları diyagram, ADR'lar karar olarak aynı repo'da durur ve CI diyagramların modelle tutarlı olduğunu her PR'da kontrol eder. Bookstore'un docs klasöründe arc42 bölümleri ile ADR ve C4 view eşlemesi, Structurizr'in !docs ve !adrs directive'leri, inspect ve bayatlık kontrolü, hangi diyagramın hangi okura gösterileceği.
ADR'dan Otomatik Kontrole: Kararları Fitness Function ve CI ile Doğrulamak
Her ADR'ın Confirmation bölümü bir fitness function'ın spesifikasyonudur: karar ya her PR'da, ya takvimle, ya production'da sürekli kontrol edilir ya da kısa bir manuel listeye düşer. Bookstore'da public API kararını oasdiff ile, bundle boyutu kararını Angular budget'larıyla, migration'ların geri alınabilirliğini bir xUnit test'iyle ve .NET destek süresini haftalık bir kontrolle gerçek çıktılarıyla doğruluyoruz.
Kararları Yaşatmak: Decision Log, Architecture Review ve Advice Process
Bir decision log ancak keşfedilebilir kaldığı ve düzenli olarak gözden geçirildiği sürece işe yarar: üretilen bir index, CI'da kontrol edilen supersede zinciri, takvim ve koşul tetikleyicileri ve ayda bir 30 dakikalık review. Bookstore'un 15 ADR'lık log'unu denetleyen bir C# tool'u, advice process ve architecture advisory forum, ADR araçlarının yazım anındaki bakım durumu ve altı kişilik ekip için minimum süreç.