İhtiyacı Anlamak: Keşif Yolculuğu

İhtiyacı Anlamak: Keşif Yolculuğu

• Bölüm 1: Giriş — Neden İhtiyacı Anlamak Bu Kadar Zor?
• Bölüm 2: Stakeholder Analizi — Doğru İnsanlarla Konuşmak
• Bölüm 3: Requirements Elicitation — İhtiyacı Ortaya Çıkarma Teknikleri
• Bölüm 4: Requirements Türleri ve Sınıflandırma
• Bölüm 5: Requirements Analiz ve Modelleme
• Bölüm 6: Use Case Temelleri — Aktörler, Sistemler ve Etkileşimler
• Bölüm 7: Use Case Yazımı — Detaylı Şablon ve Tam Örnekler
• Bölüm 8: Requirements Validation ve Kalite — Review, Walkthrough, Prototip ile Doğrulama
• Bölüm9: Requirements Yönetimi — Değişiklik Kontrolü ve Araçlar
• Bölüm 10: Use Case Realization — Tasarıma Geçiş
• Bölüm 11: User Story — Agile Dünyasının İhtiyaç İfade Biçimi
• Bölüm 12: User Story Mapping — Büyük Resmi Görmek
• Bölüm 13: Impact Mapping — Stratejik Hedeflerden İhtiyaca
• Bölüm 14: Domain Storytelling — Hikaye Anlatarak Keşif
• Bölüm 15: Event Storming — Olaylarla Keşif
• Bölüm 16: Event Modeling — Zamanın Akışını Modellemek
• Bölüm 17: Example Mapping ve BDD — Örneklerle Netleştirme
• Bölüm 18: Tekniklerin Entegrasyonu — Keşiften İnşaya

FAZ 1: TEMELLER

Bölüm 1: Giriş — Neden İhtiyacı Anlamak Bu Kadar Zor?

Yazılım projelerinin başarısızlık anatomisi, Standish Group CHAOS Report verileri, “yanlış şeyi doğru inşa etmek” ile “doğru şeyi yanlış inşa etmek” ayrımı ile seri açılır. İletişim kopuklukları ve bilgi asimetrisi Nonaka & Takeuchi’nin SECI Modeli ile açıklanır. Problem Space ile Solution Space arasındaki kritik fark ve erken çözüme atlama tuzağı Cynefin Framework üzerinden ele alınır. Requirements Engineering disiplininin tarihçesi (IEEE 830, ISO/IEC 29148) ve Elicitation → Analysis → Specification → Validation → Management yaşam döngüsü tanıtılır. Bölüm, serinin tüm bölümleri arasındaki bağlantı haritası ve DDD/EDA serileriyle ilişki ile kapanır. ***Devam etmek için tıklayınız.***

Bölüm 2: Stakeholder Analizi — Doğru İnsanlarla Konuşmak

Stakeholder kavramı Primary/Secondary, Internal/External ve Key/Shadow sınıflandırmalarıyla derinlemesine tanımlanır. Brainstorming ile sistematik 8 soru çerçevesi, Organizational Chart analizi ve Onion Diagram (soğan diyagramı) ile stakeholder identification teknikleri sunulur. Analiz matrisleri olarak Power/Interest Grid (Mendelow), RACI Matrisi ve Mitchell’in Salience Model’i (Power, Legitimacy, Urgency) uygulanır. Engagement Level Assessment beş durum (Unaware → Resistant → Neutral → Supportive → Leading) arasındaki geçişler state diagram ile modellenir. Bölüm, Proto-Persona ve Empathy Map (Dave Gray) teknikleriyle stakeholder persona’ları oluşturarak kapanır; e-commerce alıcı, satıcı ve operasyon yöneticisi persona’ları somut örnekler olarak sunulur. ***Devam etmek için tıklayınız.***

Bölüm 3: Requirements Elicitation — İhtiyacı Ortaya Çıkarma Teknikleri

Elicitation ile Gathering arasındaki felsefî fark açıklanır: requirements “toplanmaz”, “ortaya çıkarılır” çünkü ihtiyaçların büyük kısmı stakeholder’ların bilinçaltında gömülüdür (Unknown Unknowns). Interview teknikleri Structured, Semi-Structured ve Unstructured olarak üç seviyede incelenir; soru tipleri (open-ended, closed, probing, leading) ve active listening teknikleri detaylandırılır. Workshop facilitation’da JAD (Joint Application Development) sessions, before/during/after planlama ve yaygın fasilitasyon anti-pattern’leri ele alınır. Observation teknikleri passive/active observation, Contextual Inquiry (Beyer & Holtzblatt) ve Apprenticing ile derinleştirilir. Document Analysis, Legacy Reverse Engineering, Survey tasarımı ve Prototyping (throwaway, evolutionary, Wizard of Oz) ile elicitation araç kutusu tamamlanır. Bölüm, tüm tekniklerin güçlü/zayıf yönlerini ve proje tipine göre seçim matrisini sunarak kapanır. ***Devam etmek için tıklayınız.***

Bölüm 4: Requirements Türleri ve Sınıflandırma

Functional Requirements’ın ifade biçimleri (“shall statements”) ve granülasyon seviyeleri tanımlanır. Non-Functional Requirements, FURPS+ modeli (Functionality, Usability, Reliability, Performance, Supportability) çerçevesinde derinlemesine ele alınır; Performance (throughput, latency), Availability (SLA, SLO, SLI, MTBF, MTTR), Security (authentication, authorization, PCI-DSS) ve Scalability alt kategorileri ölçülebilir metriklerle somutlaştırılır. Constraints üç boyutta incelenir: Business Constraints, Technical Constraints ve Regulatory/Compliance Constraints (KVKK, GDPR, PCI-DSS). Business Rules sınıflandırması (Fact, Constraint, Action Enabler, Inference, Computation) ile Decision Table ve Decision Tree araçları tanıtılır. Assumptions ve Dependencies yönetimi risk analizi bağlantısıyla sunulur. Bölüm, Traceability Matrix (Forward, Backward, Bidirectional) ile Requirement → Design → Code → Test izlenebilirlik zincirini kurarak kapanır. ***Devam etmek için tıklayınız.***

Bölüm 5: Requirements Analiz ve Modelleme

Requirements Analysis temelleri Conflict Resolution, Requirements Negotiation ve Feasibility Analysis (TELOS: Technical, Economic, Legal, Operational, Schedule) ile başlar. Altı prioritization tekniği derinlemesine incelenir: MoSCoW Method, Kano Model (Must-be, One-dimensional, Attractive, Indifferent, Reverse), WSJF (Weighted Shortest Job First), Cost of Delay, Value/Effort Matrix ve 100 Dollar Test. Process Modeling bölümünde BPMN 2.0'ın tüm elementleri (Events, Activities, Gateways — Exclusive/Parallel/Inclusive/Event-Based, Swimlanes, Data Objects, Message Flows) e-commerce sipariş, ödeme ve iade süreçleri üzerinde uygulanır. Data Modeling Conceptual/Logical/Physical seviyelerde Entity-Relationship diyagramlarıyla, State Modeling ise Harel Statechart (Guard Conditions, Composite States, Orthogonal Regions) ile sipariş ve ödeme durum makineleri üzerinde somutlaştırılır. Bölüm, System Context Diagram ve C4 Model Context Level ile sistem sınırlarını tanımlayarak kapanır. ***Devam etmek için tıklayınız.***

FAZ 2: USE CASE DERİNLEMESİNE

Bölüm 6: Use Case Temelleri — Aktörler, Sistemler ve Etkileşimler

Use Case kavramı Ivar Jacobson’dan Alistair Cockburn’e uzanan tarihçesi ve 7 DNA bileşeni (Aktör, Hedef, Sistem Sınırı, Ön Koşul, Ana Akış, Alternatif Akışlar, Son Koşul) ile tanıtılır. Use Case vs User Story vs Feature karşılaştırması 7 boyutta yapılır. Aktörler üç kategoride (Primary, Supporting, Offstage) ve üç hiyerarşide (Alıcı: Ziyaretçi→Platinum, Satıcı: Bireysel→Kurumsal, Yönetici: CS Ajanı→Super Admin) modellenir. Sistem sınırları karar ağacı ile Sistem İçi/Dış Sistem/Kapsam Dışı olarak belirlenir. UML notasyonunda Include (zorunlu), Extend (opsiyonel) ve Generalization ilişkileri karar rehberiyle sunulur. Cockburn granülasyon seviyeleri (Summary ☁️, User Goal 🌊, Subfunction 🐟) ve “kahve molası testi” ile doğru seviye belirlenir. Beş keşif tekniği (Aktör-Hedef Listesi, Olay-Yanıt, Süreç Dekompozisyonu, CRUD Analizi, Persona Senaryoları) ve 5 anti-pattern tanıtılır. Bölüm, e-commerce platformu için 36 UC’lik tam katalog (Alıcı 12, Satıcı 10, Admin 8, Sistem 6) ve bölümler arası entegrasyon haritası ile kapanır. ***Devam etmek için tıklayınız.***

Bölüm 7: Use Case Yazımı — Detaylı Şablon ve Tam Örnekler

Use Case yazım seviyeleri Brief (5–10dk), Casual (15–30dk) ve Fully-Dressed (1–4sa) olarak tanımlanır ve MoSCoW öncelik eşlemesi yapılır. Cockburn Fully-Dressed şablonunun 14 bölüm anatomisi (Metadata 5, Koşullar 4, Akışlar 2, Ek 3) detaylı açıklanır. Ana akış yazımı için 8 altın kural sunulur: Ping-Pong ritmi, numaralandırma, aktif cümle, gözlemlenebilir davranış, UI bağımsızlık, 3–9 adım, tek soyutlama seviyesi ve başarı odaklılık. Extension numaralandırma konvansiyonu (2a, 3b, 6c, alt adımlar 2a.1, yıldız * notasyonu) ve Extension vs Exception farkı ile 4 kurtarma stratejisi (Retry, Fallback, Graceful Degradation, Safe State) ele alınır. İki tam Fully-Dressed örnek sunulur: UC-B04 “Sipariş Ver” (11 adımlık ana akış, 12 extension, 7 stakeholder, 6 BR referansı, 5 NFR) ve UC-B06 “İade Talebi Oluştur” (10 adım, 6 extension). UC-B04'ten 8 User Story’ye dönüşüm (toplam 40 SP, 2 sprint) traceability ile gösterilir. Karmaşıklık formülü (Adımlar×1 + Extensions×2 + BR×1.5 + Actors×3 + Include×4) ile UC-B04 skoru 61, UC-B06 skoru 34 olarak hesaplanır. Bölüm, UC→Test senaryolarına Given/When/Then dönüşümü (UC-B04 → 30+ test case) ile kapanır. ***Devam etmek için tıklayınız.***

Bölüm 8: Requirements Validation ve Kalite

Verification (“ürünü doğru mu yapıyoruz?” — teknik kalite) ile Validation (“doğru ürünü mü yapıyoruz?” — iş değeri) arasındaki temel fark açıklanır. IEEE 830/ISO 29148 standartlarından 8 kalite niteliği bireysel (Unambiguous, Testable, Correct, Feasible) ve küme (Consistent, Complete, Traceable, Ranked) olarak ele alınır. Üç review tekniği artan etkinlikle sunulur: Desk Check (%40 hata yakalama, 1 kişi), Walkthrough (%60, 3–7 kişi) ve Formal Inspection (%80–90, 4–6 kişi). Fagan Inspection metodu 6 aşama (Planlama → Genel Bakış → Hazırlık → Toplantı → Rework → Takip) ve 4 rol (Moderatör tarafsız, Yazar savunma yapmaz, Reviewer’lar farklı lens, Kayıtçı) ile detaylandırılır. Prototipleme ile validation 3 fazlı strateji (Low-fi Hafta 1, Medium-fi Hafta 2–3, High-fi Hafta 4) ve “bitmemiş görünüm paradoksu” ile sunulur. Cross-model tutarlılık (UC↔BPMN, UC↔State, UC↔Context, UC↔BR), Defect Taxonomy (3 ciddiyet × 6 tür — Omission %35 en yaygın), 21 maddelik Validation Master Checklist, Baseline yaşam döngüsü, Sign-off matrisi ve Boehm maliyet çarpanı (Requirements 1x → Test 20x → Production 50–100x) ile bölüm tamamlanır. ***Devam etmek için tıklayınız.***

Bölüm 9: Requirements Yönetimi — Değişiklik Kontrolü ve Araçlar

Yönetimsiz kaos (Scope Creep, Versiyon Kabusu, İzlenebilirlik Yokluğu) ile yönetimli kontrol karşılaştırılır. Requirements yaşam döngüsü 10 durumlu state diagram (Proposed → UnderReview → Approved → Baselined → ChangeRequested → Implemented → Verified → Completed → Deprecated + NeedsRevision) ile modellenir. Change Control Process’te 5 tetikleyici, CR formu, triaj (minor/önemli/acil), etki analizi ve CCB (5 üye: PO veto, Architect veto, Dev Lead, QA Lead, PM moderatör) karar mekanizması açıklanır. Somut etki analizi olarak CR-2024–042 (Havale timeout 48s→72s) 5 boyutta (requirements, tasarım, kod 2–3sa, test 1–2sa, iş etkisi) incelenir. Baseline evrimi v1.0 (Sprint 0, 65 req) → v2.0 (78 req) semantic versioning ile gösterilir. Traceability zinciri İş Hedefi → Stakeholder → Elicitation → UC → FR/NFR/BR → Tasarım → Kod → Test olarak kurulur. 6 araç karşılaştırması (IBM DOORS, Jama Connect, Jira+Confluence, Azure DevOps, Markdown+Git, Notion), Agile RM prensipleri, 6 metrik dashboard (Coverage %54, Defect Rate %72, Stability %87.7, CR 3.5gün, Scope Creep +%20), 4 anti-pattern, 5 seviyeli olgunluk modeli ve araç seçim karar ağacı ile bölüm kapanır. ***Devam etmek için tıklayınız.***

Bölüm 10: Use Case Realization — Tasarıma Geçiş

Use Case Realization, requirements ile implementasyon arasındaki köprü olarak tanımlanır: “ne yapılacak?” sorusundan “nasıl yapılacak?” sorusuna geçiş. Robustness Analysis’te 3 stereotip (Boundary — aktör-sistem arayüzü, Control — iş mantığı koordinasyonu, Entity — kalıcı veri) iletişim kurallarıyla birlikte açıklanır: Aktör→Boundary→Control→Entity zinciri izinli, Aktör→Control ve Boundary→Entity yasaktır. UC-B04 tam Robustness Diagram’ı 6 Boundary + 7 Control + 8 Entity = 21 analiz nesnesi olarak çizilir. 5 dönüşüm kuralı (aktör adımı→Boundary mesajı, sistem kontrol→Control mesajları, veri adımı→Entity erişimi, dış sistem→Adapter mesajı, extension→fragment) ile UC→Sequence Diagram dönüşümü yapılır; UC-B04 happy path 25+ mesajlık sequence diagram ve Extension 8a retry/max-retry alt fragment ile modellenir. BCE→Design Class dönüşümü (Boundary→Controller/Adapter, Control→Application Service/Domain Service, Entity→Domain Entity/Aggregate/Value Object) ile UC-B04'ten 14 tasarım sınıfı türetilir. Architecturally Significant Use Case (ASUC) seçimi 4 kriter (karmaşıklık>45, NFR driver, entegrasyon ağırlığı, teknoloji kararı) ile yapılır ve 36 UC’den 5 ASUC belirlenir. UC-B04'ten 3 ADR (Ödeme microservice, Circuit Breaker+Fallback, Event-driven post-order) türetilir. Bölüm, 7 adımlı realization süreci (8–14 adam-saat/ASUC) ve 5 yaygın hata (en yaygını: Anemic Entity) ile kapanır. ***Devam etmek için tıklayınız.***

FAZ 3: AGİLE & STRATEJİK TEKNİKLER

Bölüm 11: User Story — Agile Dünyasının İhtiyaç İfade Biçimi

User Story’nin Kent Beck/XP orijini ve Ron Jeffries’ın 3C modeli (Card — 3x5 inç konuşma başlatıcı, Conversation — değerin %80'i burada oluşur, 3 Amigos, Confirmation — Acceptance Criteria) ile felsefesi açıklanır. Üç User Story formatı karşılaştırılır: Klasik (“Rol olarak, özellik istiyorum, çünkü fayda” — WHY kısmı en kritik ama en çok atlanan), Job Story (bağlam odaklı, JTBD uyumlu) ve Feature Injection (değeri öne koyan). INVEST kriterleri her biri iyi/kötü örneklerle derinlemesine ele alınır; Vertical Slicing prensibi (tüm katmanları kesen story = değerli) ile Horizontal Slicing anti-pattern’i (sadece UI veya DB = sıfır değer) somut örneklerle karşılaştırılır. Acceptance Criteria’nın Rule-based (7 maddelik kupon örneği) ve Gherkin (Given/When/Then, somut rakamlarla 2 senaryo) formatları sunulur. Hiyerarşi Epic→Feature→User Story→Task olarak Ödeme Sistemi tam decomposition’ı ile gösterilir. Enabler Stories (Infrastructure, Architecture — ADR bağlantısı, Spike — zaman kutulu araştırma) tanıtılır. Richard Lawrence’ın 9 Story Splitting pattern’i (Workflow Steps, Business Rule Variations, Simple/Complex, Major Effort, Variations in Data, Data Entry Methods, Defer Performance, Operations/CRUD, Break Out a Spike) her biri somut örneklerle ve serinin ilgili bölümlerine referanslarla açıklanır. “Ürün Arama” 25+ SP’lik büyük story’nin 5 pattern ile 15+ story’ye split edilmesi tam pratik olarak sunulur. DoR (7 madde, sprint giriş kapısı) ve DoD (8 madde, tamamlanma kapısı) tanımlanır. UC vs US 6 boyutta karşılaştırılır ve ikisini birlikte kullanma stratejisi önerilir. 6 anti-pattern (Teknik Story, WHY’siz, Dev Story 40+ SP, Kullanıcı Genellemesi, İmplementasyon Story, AC’siz) ile bölüm kapanır. ***Devam etmek için tıklayınız.***

Bölüm 12: User Story Mapping — Büyük Resmi Görmek

Jeff Patton’ın 2005'te tanıttığı Story Mapping tekniği, Flat Backlog probleminin çözümü olarak sunulur: tek boyutlu öncelik listesi kullanıcı yolculuğunu göstermez, story’ler bağlamdan kopar ve MVP tanımlanamaz. Story Map anatomisi 4 katman olarak tanımlanır: Activities (üst düzey hedefler, Cockburn Summary Level), Backbone (kullanıcı görevleri, User Goal Level — hikaye çizgisi), Walking Skeleton (her task’ın en minimal çalışan versiyonu — uçtan uca iskelet, Cockburn/Beck konsepti), Body (zenginleştirme story’leri, priority sıralı). Story Mapping Workshop 6 adımda (~2.5 saat) açıklanır: Persona Seç (10dk) → Aktiviteleri Keşfet (15dk) → Backbone Oluştur (30dk) → Walking Skeleton (20dk) → Body Doldur (45dk) → Release Slice (30dk). E-commerce tam Story Map örneği 4 aktivite × 8 backbone × 32 story × 4 release (R1 MVP Sprint 1–4, R2 MMP Sprint 5–8, R3 Enhanced Sprint 9–12, R4 Advanced Sprint 13+) ile sunulur. Walking Skeleton kavramı derinleştirilir: prototype değil (WS üzerine inşa edilir, production kalitesinde yazılır), mimari riskleri erken ortaya çıkarır. Workshop katılımcı rolleri (PO zorunlu, Dev 2–3, QA, UX, Architect isteğe bağlı, Facilitator zorunlu/tarafsız) ve hazırlık kontrol listesi verilir. Release Slicing’de MVP (öğrenme minimum, satış değil), MMP (pazara sunulabilir minimum) ve Full Product kavramları Outcome-Based Slicing ile birleştirilir. Story Map→Product Backlog dönüşümü, fiziksel vs dijital araçlar (Miro, StoriesOnBoard, Avion) ve 5 anti-pattern (Teknik Backbone, MVP=V1, Tek Seferlik Harita, Çok Fazla Detay, Tek Persona) ile bölüm kapanır. ***Devam etmek için tıklayınız.***

Bölüm 13: Impact Mapping — Stratejik Hedeflerden İhtiyaca

Gojko Adzic’in 2012'de tanıttığı Impact Mapping, Feature Fabrikası tuzağının çözümü olarak sunulur: velocity yüksek ama ROI negatif — kimse “bu feature hangi iş hedefine hizmet ediyor?” sorusunu sormamış. Impact Map’in dört seviyeli mindmap yapısı WHY (iş hedefi, merkez) → WHO (aktörler) → HOW (davranış değişiklikleri) → WHAT (deliverables) olarak tanımlanır. WHY seviyesinde SMART Goal formatı (Specific, Measurable, Achievable, Relevant, Time-bound) her kriter yanlış/doğru örneklerle somutlaştırılır. WHO seviyesinde 3 aktör kategorisi tanıtılır: Birincil (davranışı değişmeli), İkincil (değişimi destekleyen) ve Negatif (hedefe zarar veren — sıklıkla unutulan ama kritik). HOW seviyesinde 3 yazım kuralı (fiil ile ifade et, ölçülebilir yap, feature değil davranış yaz) ve 8 somut impact ölçülebilir mevcut→hedef değerleriyle sunulur. WHAT seviyesinde 4 deliverable türü tanıtılır: yazılım özellikleri, süreç değişiklikleri (bazen en etkili deliverable bir kod satırı bile değildir), pazarlama aksiyonları ve veri/analiz. E-commerce tam Impact Map mindmap’i 1 SMART goal, 4 aktör, 8 impact, 20 deliverable ile sunulur. Assumption Mapping Importance×Uncertainty matrisi ve Build-Measure-Learn döngüsüyle (Build: minimum deney 1 sprint → Measure: 2 hafta veri → Learn: doğrulandı→geliştir / yanlışlandı→iptal) açıklanır. Impact Map→Product Backlog dönüşümü (3 adım: gruplama, US dönüşümü, traceability) ve 4 diğer teknikle karşılaştırma (Story Map, MoSCoW, Use Case, Event Storming — hepsi tamamlayıcı) ile bölüm kapanır. ***Devam etmek için tıklayınız.***

Bölüm 14: Domain Storytelling — Hikaye Anlatarak Keşif

Stefan Hofer ve Henning Schwentner’ın 2020'de tanıttığı Domain Storytelling, domain expert’lere günlük işlerini hikaye olarak anlattırarak domain keşfi yapma tekniği olarak sunulur. Tekniğin üç temel felsefesi açıklanır: bilişsel temel (insanlar 70.000 yıldır hikaye anlatıyor, domain expert UML okuyamaz ama hikaye anlatabilir), keşif gücü (hikayede aktörler, süreç, nesneler, kurallar ve istisnalar doğal olarak gömülüdür) ve işbirliği (domain expert anlatır, modeler çizer, ekip sorar = Ubiquitous Language keşfi). 5 notasyon elementi tanıtılır: Actors (ikon+isim, cümle öznesi), Work Objects (ikon+isim, Entity adayları), Activities (numaralı oklar, kronolojik fiiller), Annotations (yan bilgi, Business Rule keşfinin altın madeni) ve Groups (kesikli kutu, Bounded Context adayları). Coarse-Grained (5–10 adım, büyük resim) vs Fine-Grained (10–15 adım, detaylı analiz) hikaye granülasyonu ve JIT detay stratejisi açıklanır. AS-IS (mevcut durum: telefon, Excel %15 hata, faks %5 kayıp) vs TO-BE (hedef durum: web, gerçek zamanlı, otomatik) hikayeleri ve Gap Analysis (her fark ölçülebilir bir gereksinime dönüşür) sunulur. E-commerce sipariş hikayesi 14 adımlık fine-grained TO-BE olarak UC-B04'ün Domain Storytelling karşılığı şeklinde modellenir. Bounded Context keşfi için 3 sinyal tanımlanır: aynı terim farklı anlam (“Sipariş” = Order/Picking Order/Shipment → 3 BC), farklı aktörler farklı hikayeler, handoff noktaları (hikaye biter → başka başlar = BC sınırı + Domain Event adayı). Workshop 3 saat, 6 adım ve 3 rol (Domain Expert anlatıcı, Modeler çizici, Audience soru sorucu) ile detaylandırılır. Ubiquitous Language keşfi 3 adımlı süreçle (terimleri listele → karşılaştır → sözlüğe kaydet), 4 teknikle karşılaştırma (UC, Event Storming, BPMN, Impact Mapping — DS hepsinin doğal hazırlığıdır) ve 5 anti-pattern (en kritik: Domain Expert’i düzeltme) ile bölüm kapanır. ***Devam etmek için tıklayınız.***

FAZ 4: EVENT-DRIVEN KEŞİF & SENTEZ

Bölüm 15: Event Storming — Olaylarla Keşif

Alberto Brandolini’nin 2013'te geliştirdiği Event Storming, “sistemde olan her şey bir olaydır — olayları keşfedersen sistemi keşfedersin” felsefesiyle sunulur. 4 temel prensip tanımlanır: Unlimited Modeling Space (8–10m duvar, küçük alan yasak), Herkes Katılır (10–20+ kişi, kaos kasıtlı — DS’den en büyük fark), Düşük Sadakat (sticky note 5 kuruş, yırt at), Event-First Thinking (“ne oldu?” geçmiş zaman — entity-first veya function-first değil). 8 notasyon elementi renk kodlarıyla tanıtılır: Domain Event (turuncu, geçmiş zaman — en temel), Command (mavi, emir kipi), Actor (sarı küçük), Aggregate (sarı büyük, DDD Aggregate Root = kuralların sahibi), Policy (mor, “bu olduğunda şunu yap” = Event→Command dönüştürücü = Saga keşfi), Read Model (yeşil, sorgu görünümü = CQRS keşfi), External System (pembe, dış entegrasyon) ve Hot Spot (parlak kırmızı, sorunlar/sorular). Big Picture 6 adımda (2–3 saat) açıklanır: Chaotic Exploration (20–30dk, 50–100+ event, kaos), Enforce Timeline (30–45dk, kronolojik sıralama, tartışma başlar), Pivotal Events (dönüm noktaları = BC sınırları), Swimlanes (paralel akışlar), Bounded Contexts (3 sinyal) ve Hot Spots. E-commerce Big Picture tam örneği 24 Domain Event, 3 Pivotal Event (SiparişOluşturuldu, ÖdemeBaşarılı, KargoyaVerildi) ve 6 Bounded Context (Catalog, Shopping, Ordering, Payment, Fulfillment, After-Sale) ile sunulur. Process Level’da 4 temel zincir açıklanır: Actor→Command→Aggregate→Event (temel), Event→Policy→Command→Aggregate→Event (Saga keşfi), Events→Read Model→Actor→Command (CQRS keşfi), Command→External System→Event (Adapter). Ordering BC tam Process Level örneği tüm 8 elementi kullanarak modellenir. Design Level’da Aggregate detay (state, command validation, event payload) ile implementasyona en yakın seviye tanımlanır. Facilitation ipuçları, Remote Event Storming kuralları, ES vs DS 5 boyutlu karşılaştırma, DDD/Microservice dönüşümü (Aggregate→Aggregate Root, Policy→Saga, BC→Microservice adayı, Pivotal Events→Kafka topics) ve 5 anti-pattern ile bölüm kapanır. ***Devam etmek için tıklayınız.***

Bölüm 16: Event Modeling — Zamanın Akışını Modellemek

Adam Dymitruk’un 2019'da tanıttığı Event Modeling, yazılım sistemlerinin tam tasarım planı (blueprint) olarak sunulur. Bina blueprint’i analojisi kullanılır: Event Storming arsayı gezmek (keşif), Event Modeling mimari planı çizmektir (blueprint). 4 swimlane yapısı tanımlanır: UI/Screens (en üst, wireframe — ES’de yoktu, EM’de var = PO+UX katılımı), Commands (üst-orta, parametreli = API endpoint girdisi), Events (alt-orta, payload’lı timeline = Event Sourcing girdisi, sistemin hafızası), Read Models/Views (en alt, event projeksiyonu = CQRS Query Side). 4 temel pattern açıklanır: Command Pattern (UI→Command→Event = CQRS yazma tarafı, validation), View/Read Pattern (Events→Read Model→UI = CQRS okuma tarafı, eventual consistency), Automation/Translation Pattern (Event→Policy→Command→Event = Saga/Process Manager, insan müdahalesi yok) ve External System Pattern (Command→External→Event, Outbound/Inbound, Adapter+Circuit Breaker). Bu 4 pattern ile tüm yazılım sistemlerinin modellenebileceği vurgulanır. 7 adımlı oluşturma süreci (~3.5 saat) açıklanır. E-commerce sipariş akışı tam Event Model olarak 5 zaman diliminde (Sepet Onay → Ödeme → Onay Otomasyonu → Paralel İşlemler → Takip) UC-B04'ün event-driven blueprint karşılığı şeklinde sunulur. Specification by Example dönüşümü GIVEN (geçmiş event’ler) / WHEN (command) / THEN (üretilen event’ler) kuralıyla 3 test senaryosu (başarılı sipariş, stok yetersiz, ödeme retry) türetilir. CQRS+Event Sourcing implementasyon dönüşümü her pattern için Java sınıf eşlemeleriyle verilir. ES vs EM 7 boyutlu karşılaştırma (en büyük fark: UI — ES’de yok, EM’de var), Workshop (4 blok, 3 saat) ve 5 anti-pattern (en kritik: UI atlama — EM’nin ayırt edici özelliği) ile bölüm kapanır. ***Devam etmek için tıklayınız.***

Bölüm 17: Example Mapping ve BDD — Örneklerle Netleştirme

Matt Wynne’ın (Cucumber yaratıcısı) Example Mapping tekniği, soyut User Story’leri somut örneklerle netleştirmenin sistematik yolu olarak sunulur. Temel problem: PO, developer ve tester aynı story’den farklı şeyler anlıyor ama kimse fark etmiyor; sprint ortasında “ben bunu böyle anlamıştım” tartışması başlıyor. 4 renk kart sistemi tanıtılır: Sarı (Story, tek kart, en üst), Mavi (Rule = iş kuralı, sütunlar = Bölüm 4 BR keşfi), Yeşil (Example = somut senaryo, satırlar = Given/When/Then ham hali) ve Kırmızı (Question = açık soru, çözülmez kaydedilir = Hot Spot). Session 5 adımda 25dk time-box ile açıklanır: Story kartı (2dk) → İlk Rules (5dk, PO) → Examples (12dk, EN UZUN, Dev+QA aktif, yeni rule keşfi) → Questions (3dk, kaydet) → Değerlendir (3dk: az rule→READY, çok rule→SPLIT, çok soru→SPIKE). İki tam pratik sunulur: “Sepete Ürün Ekle” (4 Rule, 9 Example, 2 Question → 3 story’ye split) ve “Kupon Uygula” (6 Rule, 11 Example, 3 Question — Rule 5 “indirim üst sınır” session’da developer sorusuyla keşfedildi). Example Mapping→Gherkin dönüşümü (Story→Feature başlık, Rule→Rule: keyword, Example→Scenario:, Question→TODO) tam Feature dosyası örneğiyle gösterilir. BDD yaşam döngüsü Dan North'un (2003) Discovery→Formulation→Automation modeli ile açıklanır; en kritik mesaj: BDD ≠ test otomasyonu, BDD'nin %80 değeri Discovery (Example Mapping) adımındadır. Specification by Example Gojko Adzic'in (2011) 6 anahtar pattern'i (hedeflerden kapsam, işbirlikçi spec, örneklerle açıklama, spec iyileştirme, otomatik doğrulama, yaşayan dokümantasyon) ile serinin Bölüm 13-17 tekniklerinin birleşik çerçevesi olarak sunulur. Living Documentation (Feature dosyaları hem spec hem test, CI'da her commit çalışır, doküman kendini doğrular) ile geleneksel Shelfware karşılaştırılır. 5 anti-pattern (en kritik: Discovery atlama — %80 değer kayıp) ile bölüm kapanır. ***Devam etmek için tıklayınız.***

Bölüm 18: Tekniklerin Entegrasyonu — Keşiften İnşaya

Serinin final bölümü, 17 bölümde ele alınan tüm tekniklerin nasıl birlikte kullanılacağını sentezler. 4 fazlı büyük resim (Temeller → Use Case → Agile & Strateji → Event-Driven) ve UC-B04'ün seri boyunca omurga olarak kullanımı özetlenir. 8 teknik × 8 boyut karşılaştırma matrisi (odak, katılımcı, süre, detay, mimari etki, çıktı, yaşam süresi, ideal kullanım) sunulur. 5 kanıtlanmış hibrit kombinasyon tanımlanır: Stratejik Keşif Zinciri (Impact Map→Story Map→Example Mapping), Domain Keşif Zinciri (DS→ES→EM — altın standart), UC+Agile Köprüsü (UC→US→Example Mapping), Tam Realization Zinciri (UC→Realization→EM→CQRS Code) ve Sürekli Doğrulama (Validation→BDD→Living Doc). Keşif→İmplementasyon tam geçiş haritası 5 faz (Keşif→Modelleme→Spesifikasyon→Tasarım→İmplementasyon) ile verilir. E-commerce uçtan uca vaka çalışması 8 adımda (Stakeholder→Impact Map→DS→ES→UC+Story Map→EM→ExM+BDD→Realization) tüm tekniklerin ardışık uygulanmasını gösterir. Proje tipine göre teknik seçim karar ağacı 5 profil (Startup/MVP, Enterprise, DDD/Microservice, Dijitalleşme, Agile Dönüşüm) için sunulur. Teresa Torres’in Continuous Discovery Habits (2021) ve Opportunity Solution Tree konsepti serinin tekniklerinin sürekli uygulanmasının çerçevesi olarak tanıtılır. Dual-Track Agile modeli Discovery Track + Delivery Track paralel yapısı ve Product Trio (PM+Designer+Tech Lead) ile açıklanır. 5 seviyeli organizasyonel olgunluk modeli (Ad-Hoc→Reaktif→Yapılandırılmış→Proaktif→Optimize) sunulur. Seri boyunca keşfedilen Top 10 Anti-Pattern (Shelfware, Analysis Paralysis, Feature Fabrikası, Horizontal Slicing, Anemic Entity, God Aggregate, Discovery Atlama, Teknik Backbone, Domain Expert Düzeltme, MVP=V1) derlenir. Seri, 3 temel ilke ile kapanır: Doğru Şeyi İnşa Et (NEDEN?), İnsanlarla Konuş (konuşma > doküman) ve Sürekli Öğren (keşif asla bitmez). ***Devam etmek için tıklayınız.***