Kommunikation, Entscheidungen und Projektpraxis
Ein chronologischer, dreisprachiger Leitfaden vom Problemverständnis über Sandbox, Implementierung und Go-live bis zur Modernisierung. English · Deutsch · Türkçe.
Sprachprinzip: Ein Architekt nennt nicht nur eine Technologie. Er beschreibt Problem, Ziel, Rahmenbedingungen, Trade-offs, Entscheidung, Konsequenzen und den geplanten Nachweis.
Projektphase 1
Current state and problem framingMevcut durum ve problem anlayışı
Before proposing a solution, the architect clarifies the business problem, current state, stakeholders, and scope.
Bevor eine Lösung vorgeschlagen wird, klärt der Architekt das geschäftliche Problem, den Ist-Zustand, die Stakeholder und den Scope.
Bir çözüm önermeden önce mimar iş problemini, mevcut durumu, paydaşları ve kapsamı netleştirir.
| English | Deutsch | Türkçe |
|---|---|---|
| What problem are we solving? | Welches Problem lösen wir? | Hangi problemi çözüyoruz? |
| We need to understand the current system before proposing a target architecture. | Bevor wir eine Zielarchitektur vorschlagen, müssen wir das bestehende System verstehen. | Hedef mimari önermeden önce mevcut sistemi anlamamız gerekir. |
| Let us separate symptoms from root causes. | Lassen Sie uns Symptome und Ursachen voneinander trennen. | Belirtileri kök nedenlerden ayıralım. |
Projektphase 2
Requirements and constraintsGereksinimler ve kısıtlar
Functional requirements are considered separately from quality goals, regulatory constraints, budget, time, and operational boundaries.
Funktionale Anforderungen werden von Qualitätszielen, regulatorischen Vorgaben, Budget, Zeit und Betriebsgrenzen getrennt betrachtet.
İşlevsel gereksinimler; kalite hedefleri, mevzuat kısıtları, bütçe, zaman ve operasyonel sınırlar ile ayrı değerlendirilir.
| English | Deutsch | Türkçe |
|---|---|---|
| What are the non-functional requirements? | Welche nichtfunktionalen Anforderungen bestehen? | İşlevsel olmayan gereksinimler nelerdir? |
| Which constraints are fixed, and which are negotiable? | Welche Rahmenbedingungen sind fest und welche verhandelbar? | Hangi kısıtlar sabit, hangileri müzakere edilebilir? |
| This requirement has operational and security implications. | Diese Anforderung hat betriebliche und sicherheitsrelevante Auswirkungen. | Bu gereksinimin operasyonel ve güvenlik açısından etkileri vardır. |
Projektphase 3
System boundaries and business domainsSistem sınırları ve iş alanları
Responsibilities, data ownership, bounded contexts, and integration boundaries are made explicit.
Verantwortlichkeiten, Datenhoheit, Bounded Contexts und Integrationsgrenzen werden sichtbar gemacht.
Sorumluluklar, veri sahipliği, bounded context'ler ve entegrasyon sınırları görünür hale getirilir.
| English | Deutsch | Türkçe |
|---|---|---|
| We need a clear system boundary. | Wir benötigen eine klare Systemgrenze. | Net bir sistem sınırına ihtiyacımız var. |
| Which domain owns this capability? | Welche Domäne verantwortet diese Fähigkeit? | Bu yeteneğin sahibi hangi iş alanıdır? |
| This responsibility belongs to a different bounded context. | Diese Verantwortung gehört in einen anderen Bounded Context. | Bu sorumluluk farklı bir bounded context'e aittir. |
Projektphase 4
Architecture goals and principlesMimari hedefler ve ilkeler
Before selecting technologies, goals such as maintainability, security, resilience, evolvability, and observability are prioritized.
Vor der Technologieauswahl werden Ziele wie Wartbarkeit, Sicherheit, Resilience, Änderbarkeit und Beobachtbarkeit priorisiert.
Teknoloji seçiminden önce bakım kolaylığı, güvenlik, dayanıklılık, değişebilirlik ve gözlemlenebilirlik gibi hedefler önceliklendirilir.
| English | Deutsch | Türkçe |
|---|---|---|
| The architecture should support independent evolution. | Die Architektur soll eine unabhängige Weiterentwicklung ermöglichen. | Mimari bağımsız gelişimi desteklemelidir. |
| We should optimize for maintainability, not only initial delivery speed. | Wir sollten auf Wartbarkeit optimieren, nicht nur auf die anfängliche Liefergeschwindigkeit. | Yalnızca ilk teslim hızına değil, bakım kolaylığına da odaklanmalıyız. |
| Observability is a design concern, not an afterthought. | Observability ist ein Entwurfsziel und kein nachträglicher Zusatz. | Gözlemlenebilirlik sonradan eklenen bir özellik değil, tasarım konusudur. |
Projektphase 5
Solution options and trade-offsÇözüm seçenekleri ve ödünleşimler
Architecture options are compared against requirements, not trends.
Architekturoptionen werden anhand der Anforderungen verglichen, nicht anhand von Trends.
Mimari seçenekler trendlere göre değil, gereksinimlere göre karşılaştırılır.
| English | Deutsch | Türkçe |
|---|---|---|
| We should compare the trade-offs before making a decision. | Wir sollten die Trade-offs vergleichen, bevor wir entscheiden. | Karar vermeden önce ödünleşimleri karşılaştırmalıyız. |
| This option reduces coupling but increases operational complexity. | Diese Option reduziert die Kopplung, erhöht jedoch die betriebliche Komplexität. | Bu seçenek bağımlılığı azaltır ancak operasyonel karmaşıklığı artırır. |
| What do we gain, and what do we give up? | Was gewinnen wir und worauf verzichten wir? | Ne kazanıyoruz ve nelerden vazgeçiyoruz? |
Projektphase 6
Architecture decision and ADRMimari karar ve ADR
Context, options, decision, rationale, consequences, and review criteria are documented transparently.
Kontext, Optionen, Entscheidung, Begründung, Konsequenzen und Überprüfungskriterien werden nachvollziehbar dokumentiert.
Bağlam, seçenekler, karar, gerekçe, sonuçlar ve gözden geçirme kriterleri şeffaf biçimde belgelenir.
| English | Deutsch | Türkçe |
|---|---|---|
| We selected asynchronous messaging because consumers must evolve independently. | Wir haben asynchrones Messaging gewählt, weil die Consumer unabhängig weiterentwickelt werden müssen. | Tüketicilerin bağımsız gelişebilmesi gerektiği için asenkron mesajlaşmayı seçtik. |
| This decision is valid under the documented assumptions. | Diese Entscheidung gilt unter den dokumentierten Annahmen. | Bu karar belgelenen varsayımlar altında geçerlidir. |
| We will revisit the decision when the load profile changes. | Wir überprüfen die Entscheidung erneut, wenn sich das Lastprofil ändert. | Yük profili değiştiğinde kararı yeniden değerlendireceğiz. |
Vertiefung
Decisions, trade-offs, and ADR languageKararlar, ödünleşimler ve ADR dili
An architecture decision is not a technology choice without context. It connects the problem, quality goals, options, evidence, consequences, and a future review point.
Eine Architekturentscheidung ist keine Technologiewahl ohne Kontext. Sie verbindet Problem, Qualitätsziele, Optionen, Nachweise, Konsequenzen und einen späteren Überprüfungszeitpunkt.
Mimari karar, bağlamsız bir teknoloji seçimi değildir. Problem, kalite hedefleri, seçenekler, kanıtlar, sonuçlar ve gelecekteki gözden geçirme noktasını birbirine bağlar.
| Aspekt | English | Deutsch | Türkçe |
|---|---|---|---|
| Nutzen | This option reduces runtime coupling and allows consumers to scale independently. | Diese Option reduziert die Laufzeitkopplung und ermöglicht eine unabhängige Skalierung der Consumer. | Bu seçenek çalışma zamanı bağımlılığını azaltır ve tüketicilerin bağımsız ölçeklenmesini sağlar. |
| Kosten | The benefit comes with additional operational complexity and delayed consistency. | Dem Nutzen stehen zusätzlicher Betriebsaufwand und verzögerte Konsistenz gegenüber. | Bu fayda ek operasyonel karmaşıklık ve gecikmeli tutarlılık maliyeti getirir. |
| Risiko | The main risk is not the broker itself, but insufficient ownership of schemas, retries, and failure handling. | Das Hauptrisiko ist nicht der Broker selbst, sondern unklare Verantwortung für Schemas, Wiederholungen und Fehlerbehandlung. | Temel risk brokerın kendisi değil; şemalar, yeniden denemeler ve hata yönetimi için sahipliğin belirsiz olmasıdır. |
| Entscheidung | We accept this trade-off because independent processing is more important than immediate consistency for this workflow. | Wir akzeptieren diesen Trade-off, weil für diesen Ablauf unabhängige Verarbeitung wichtiger ist als sofortige Konsistenz. | Bu süreçte bağımsız işleme anlık tutarlılıktan daha önemli olduğu için bu ödünleşimi kabul ediyoruz. |
EN: The current synchronous chain causes cascading failures during peak load.
DE: Die aktuelle synchrone Kette führt bei Spitzenlast zu kaskadierenden Ausfällen.
TR: Mevcut senkron zincir yoğun yükte zincirleme arızalara yol açıyor.
EN: The primary drivers are failure isolation, independent scaling, and auditable processing.
DE: Ausschlaggebend sind Fehlerisolation, unabhängige Skalierung und nachvollziehbare Verarbeitung.
TR: Temel etkenler hata izolasyonu, bağımsız ölçekleme ve denetlenebilir işlemedir.
EN: We will introduce asynchronous domain events between the order and fulfillment contexts.
DE: Zwischen Bestell- und Fulfillment-Kontext führen wir asynchrone Domänenereignisse ein.
TR: Sipariş ve teslimat bağlamları arasında asenkron alan olayları kullanacağız.
EN: Services can fail independently, but duplicate delivery, ordering, and delayed consistency must be handled explicitly.
DE: Services können unabhängig ausfallen; doppelte Zustellung, Reihenfolge und verzögerte Konsistenz müssen jedoch explizit behandelt werden.
TR: Servisler bağımsız arızalanabilir; ancak yinelenen teslimat, sıralama ve gecikmeli tutarlılık açıkça ele alınmalıdır.
EN: The sandbox must demonstrate recovery after consumer failure without data loss.
DE: Die Sandbox muss die Wiederherstellung nach einem Consumer-Ausfall ohne Datenverlust nachweisen.
TR: Sandbox, tüketici arızasından sonra veri kaybı olmadan toparlanmayı göstermelidir.
EN: Revisit the decision if end-to-end latency exceeds the agreed SLO or operational ownership changes.
DE: Die Entscheidung wird erneut geprüft, wenn die Ende-zu-Ende-Latenz das vereinbarte SLO überschreitet oder sich die Betriebsverantwortung ändert.
TR: Uçtan uca gecikme kararlaştırılan SLO'yu aşarsa veya operasyonel sahiplik değişirse karar yeniden değerlendirilir.
| Unpräzise | Professioneller |
|---|---|
| „Wir nehmen Kafka, weil es skalierbar ist.“ | „Wir benötigen unabhängige Consumer, Wiederholbarkeit und Entkopplung bei Spitzenlast. Kafka ist eine Option; der zusätzliche Betriebsaufwand und die Konsistenzfolgen werden im Sandbox-Nachweis bewertet.“ |
| “Microservices are more modern.” | “We choose service boundaries only where independent ownership and deployment provide measurable value; otherwise, modularity inside one deployable unit is preferable.” |
| “Bu karar kalıcıdır.” | “Bu karar mevcut varsayımlar altında geçerlidir; yük profili, sahiplik veya düzenleyici gereksinimler değişirse yeniden değerlendirilecektir.” |
Projektphase 7
Sandbox and technical validationSandbox ve teknik doğrulama
After a justified architecture decision, an isolated sandbox is provisioned. It is not a smaller production environment; it is a controlled space for testing the riskiest assumptions with minimal effort.
Nach einer begründeten Architekturentscheidung wird eine isolierte Sandbox bereitgestellt. Sie dient nicht als verkleinerte Produktion, sondern als kontrollierter Raum, um die risikoreichsten Annahmen mit minimalem Aufwand zu überprüfen.
Gerekçelendirilmiş mimari karardan sonra izole bir sandbox ortamı hazırlanır. Bu ortam üretimin küçük bir kopyası değil, en riskli varsayımları en az çabayla sınamak için kontrollü bir alandır.
| Situation | English | Deutsch | Türkçe |
|---|---|---|---|
| Umgebung bereitstellen | We provision the sandbox through infrastructure as code. | Wir stellen die Sandbox über Infrastructure as Code bereit. | Sandbox ortamını Infrastructure as Code ile oluşturuyoruz. |
| PoC eingrenzen | The proof of concept must answer one explicit feasibility or risk question. | Der Proof of Concept muss eine ausdrücklich formulierte Machbarkeits- oder Risikofrage beantworten. | Proof of Concept açıkça tanımlanmış bir uygulanabilirlik veya risk sorusunu yanıtlamalıdır. |
| Spike abgrenzen | This spike is time-boxed and will not become production code. | Dieser Spike ist zeitlich begrenzt und wird nicht zu Produktionscode weiterentwickelt. | Bu spike zamanla sınırlandırılmıştır ve üretim koduna dönüşmeyecektir. |
| Erfolg messen | We define exit criteria before starting the validation. | Wir definieren die Abschlusskriterien, bevor die Validierung beginnt. | Doğrulamaya başlamadan önce çıkış kriterlerini tanımlarız. |
| Ergebnis entscheiden | The evidence supports the option, but the operational cost remains a trade-off. | Die Nachweise stützen die Option, der betriebliche Aufwand bleibt jedoch ein Trade-off. | Kanıtlar seçeneği destekliyor; ancak operasyonel maliyet bir ödünleşim olarak kalıyor. |
Abgrenzung: Sandbox = frühes Experimentieren; Development = tägliche Implementierung; Integration/Test = gemeinsames Prüfen; Staging = produktionsnahe Freigabeprobe; Production = realer Geschäftsbetrieb.
Projektphase 8
Development and platform environmentGeliştirme ve platform ortamı
After successful validation, a reproducible development baseline is established with repository, build, CI/CD, configuration, and platform services.
Nach erfolgreicher Validierung entsteht eine reproduzierbare Entwicklungsbasis mit Repository, Build, CI/CD, Konfiguration und Plattformdiensten.
Başarılı doğrulamadan sonra repository, build, CI/CD, yapılandırma ve platform servisleriyle tekrarlanabilir bir geliştirme temeli kurulur.
| English | Deutsch | Türkçe |
|---|---|---|
| We now establish the development baseline. | Jetzt schaffen wir die technische Grundlage für die Entwicklung. | Şimdi geliştirme için teknik temeli oluşturuyoruz. |
| The environment should be reproducible and automated. | Die Umgebung soll reproduzierbar und automatisiert sein. | Ortam tekrarlanabilir ve otomatik olmalıdır. |
| Configuration must be externalized from the application artifact. | Die Konfiguration muss vom Anwendungsartefakt getrennt werden. | Yapılandırma uygulama artefaktından ayrılmalıdır. |
Projektphase 9
Implementation and architecture conformanceUygulama ve mimariye uygunluk
During implementation, module boundaries, dependency rules, API contracts, error handling, and technical debt are reviewed.
Während der Umsetzung werden Modulgrenzen, Abhängigkeitsregeln, API-Verträge, Fehlerbehandlung und technische Schulden geprüft.
Uygulama sırasında modül sınırları, bağımlılık kuralları, API sözleşmeleri, hata yönetimi ve teknik borç gözden geçirilir.
| English | Deutsch | Türkçe |
|---|---|---|
| This implementation violates the intended module boundary. | Diese Implementierung verletzt die vorgesehene Modulgrenze. | Bu uygulama tasarlanan modül sınırını ihlal ediyor. |
| We should avoid introducing a hidden dependency. | Wir sollten keine versteckte Abhängigkeit einführen. | Gizli bir bağımlılık oluşturmaktan kaçınmalıyız. |
| The code should express the architectural intent. | Der Code soll die architektonische Absicht sichtbar machen. | Kod mimari amacı görünür kılmalıdır. |
Projektphase 10
Integration and interfacesEntegrasyon ve arayüzler
Contracts, versioning, failure cases, timeouts, retries, and backward compatibility are defined at every integration boundary.
Verträge, Versionierung, Fehlerfälle, Timeouts, Wiederholungen und Rückwärtskompatibilität werden an jeder Integrationsgrenze definiert.
Her entegrasyon sınırında sözleşmeler, sürümleme, hata durumları, zaman aşımları, tekrar denemeler ve geriye dönük uyumluluk tanımlanır.
| English | Deutsch | Türkçe |
|---|---|---|
| The integration must remain backward compatible. | Die Integration muss abwärtskompatibel bleiben. | Entegrasyon geriye dönük uyumlu kalmalıdır. |
| We need to define failure handling at the integration boundary. | Wir müssen die Fehlerbehandlung an der Integrationsgrenze definieren. | Entegrasyon sınırındaki hata yönetimini tanımlamalıyız. |
| The API contract is a product, not an implementation detail. | Der API-Vertrag ist ein Produkt und kein Implementierungsdetail. | API sözleşmesi bir üründür, uygulama detayı değildir. |
Projektphase 11
Data, transactions, and consistencyVeri, işlemler ve tutarlılık
Data ownership, transaction boundaries, consistency model, idempotency, migration, and recovery are decided explicitly.
Datenhoheit, Transaktionsgrenzen, Konsistenzmodell, Idempotenz, Migration und Wiederherstellung werden explizit entschieden.
Veri sahipliği, işlem sınırları, tutarlılık modeli, idempotency, migration ve recovery açıkça kararlaştırılır.
| English | Deutsch | Türkçe |
|---|---|---|
| Which system owns this data? | Welches System besitzt die Datenhoheit? | Bu verinin sahibi hangi sistemdir? |
| We accept eventual consistency for this workflow. | Für diesen Ablauf akzeptieren wir Eventual Consistency. | Bu iş akışı için eventual consistency kabul ediyoruz. |
| The operation must be idempotent because retries are expected. | Die Operation muss idempotent sein, weil Wiederholungen zu erwarten sind. | Tekrar denemeler beklendiği için işlem idempotent olmalıdır. |
Projektphase 12
Security and complianceGüvenlik ve uyumluluk
Identity, access, secrets, encryption, auditability, privacy, and regulatory evidence are treated as architecture concerns.
Identität, Zugriff, Geheimnisse, Verschlüsselung, Auditierbarkeit, Datenschutz und regulatorische Nachweise werden als Architekturbelange behandelt.
Kimlik, erişim, secret'lar, şifreleme, denetlenebilirlik, gizlilik ve mevzuat kanıtları mimari konular olarak ele alınır.
| English | Deutsch | Türkçe |
|---|---|---|
| Access must follow the principle of least privilege. | Zugriffe müssen dem Prinzip der minimalen Rechte folgen. | Erişimler en az ayrıcalık ilkesine uymalıdır. |
| We need an auditable authorization model. | Wir benötigen ein auditierbares Autorisierungsmodell. | Denetlenebilir bir yetkilendirme modeline ihtiyacımız var. |
| Security controls must be testable and observable. | Sicherheitskontrollen müssen testbar und beobachtbar sein. | Güvenlik kontrolleri test edilebilir ve gözlemlenebilir olmalıdır. |
Projektphase 13
Testing, quality, and architecture validationTest, kalite ve mimari doğrulama
The solution is validated against functional requirements, quality goals, and architecture rules.
Die Lösung wird gegen funktionale Anforderungen, Qualitätsziele und Architekturregeln validiert.
Çözüm işlevsel gereksinimlere, kalite hedeflerine ve mimari kurallara göre doğrulanır.
| English | Deutsch | Türkçe |
|---|---|---|
| We need evidence that the architecture meets the quality requirements. | Wir benötigen Nachweise, dass die Architektur die Qualitätsanforderungen erfüllt. | Mimarinin kalite gereksinimlerini karşıladığına dair kanıta ihtiyacımız var. |
| A passing unit test does not prove system resilience. | Ein erfolgreicher Unit-Test beweist noch keine Systemresilienz. | Başarılı bir birim testi sistem dayanıklılığını kanıtlamaz. |
| Architecture rules should be automated where possible. | Architekturregeln sollten soweit möglich automatisiert geprüft werden. | Mimari kurallar mümkün olduğunca otomatik doğrulanmalıdır. |
Projektphase 14
Staging and production readinessStaging ve üretime hazırlık
Production-like configuration, migration, runbooks, monitoring, rollback, and responsibilities are tested before go-live.
Produktionsnahe Konfiguration, Migration, Runbooks, Monitoring, Rollback und Verantwortlichkeiten werden vor dem Go-live getestet.
Üretim benzeri yapılandırma, migration, runbook'lar, monitoring, rollback ve sorumluluklar canlıya geçişten önce test edilir.
| English | Deutsch | Türkçe |
|---|---|---|
| Once validation is complete, we promote the solution to staging. | Nach erfolgreicher Validierung überführen wir die Lösung nach Staging. | Doğrulama tamamlandıktan sonra çözümü staging ortamına taşıyoruz. |
| We need a tested rollback strategy before production deployment. | Vor dem Produktions-Deployment benötigen wir eine getestete Rollback-Strategie. | Üretim dağıtımından önce test edilmiş bir rollback stratejisine ihtiyacımız var. |
| Operational ownership must be clear before go-live. | Die betriebliche Verantwortung muss vor dem Go-live geklärt sein. | Canlıya geçişten önce operasyonel sorumluluk net olmalıdır. |
Abnahmekriterien, Security-Freigaben und offene Risiken sind transparent.
Artefakt, Konfiguration und Infrastruktur entsprechen dem geplanten Release.
Rollback, Restore und Wiederanlauf wurden praktisch erprobt.
Dashboards, Alerts, Runbooks und Ownership sind einsatzbereit.
| English | Deutsch | Türkçe |
|---|---|---|
| Staging should be production-like where the remaining risks depend on production behavior. | Staging soll dort produktionsnah sein, wo verbleibende Risiken vom Produktionsverhalten abhängen. | Kalan risklerin üretim davranışına bağlı olduğu alanlarda staging üretime benzer olmalıdır. |
| A successful deployment is not the same as a successful release. | Ein erfolgreiches Deployment ist nicht automatisch ein erfolgreiches Release. | Başarılı bir deployment, otomatik olarak başarılı bir release anlamına gelmez. |
| We will not approve go-live while the recovery procedure remains untested. | Solange das Wiederherstellungsverfahren nicht getestet ist, geben wir den Go-live nicht frei. | Kurtarma prosedürü test edilmeden canlıya geçişi onaylamayacağız. |
Projektphase 15
Go-live and production operationCanlıya geçiş ve üretim işletimi
The rollout is controlled, observable, and governed by clear abort or rollback criteria.
Die Einführung erfolgt kontrolliert, beobachtbar und mit klaren Abbruch- oder Rollback-Kriterien.
Canlıya geçiş kontrollü, gözlemlenebilir ve net durdurma ya da rollback kriterleriyle yürütülür.
| English | Deutsch | Türkçe |
|---|---|---|
| We should deploy gradually and monitor the system closely. | Wir sollten schrittweise deployen und das System eng überwachen. | Kademeli dağıtım yapmalı ve sistemi yakından izlemeliyiz. |
| The go-live decision depends on measurable readiness criteria. | Die Go-live-Entscheidung basiert auf messbaren Bereitschaftskriterien. | Canlıya geçiş kararı ölçülebilir hazırlık kriterlerine dayanır. |
| We stop the rollout if the error budget is exceeded. | Wir stoppen den Rollout, wenn das Fehlerbudget überschritten wird. | Hata bütçesi aşılırsa dağıtımı durdururuz. |
| English | Deutsch | Türkçe |
|---|---|---|
| We start with a limited cohort and expand only when the signals remain healthy. | Wir beginnen mit einer begrenzten Nutzergruppe und erweitern nur bei stabilen Signalen. | Sınırlı bir kullanıcı grubuyla başlar, sinyaller sağlıklı kaldığında kapsamı genişletiriz. |
| The rollback decision is based on pre-agreed thresholds, not intuition. | Die Rollback-Entscheidung basiert auf vorab vereinbarten Schwellenwerten und nicht auf Intuition. | Rollback kararı sezgiye değil, önceden kararlaştırılmış eşiklere dayanır. |
| Hypercare ends when ownership, support, and system behavior are stable. | Die Hypercare-Phase endet, wenn Verantwortung, Support und Systemverhalten stabil sind. | Hypercare dönemi sorumluluk, destek ve sistem davranışı istikrarlı olduğunda sona erer. |
Vertiefung
Distinguishing delivery environmentsTeslim ortamlarını doğru ayırt etmek
| Umgebung | Primärer Zweck | Typische Architektensprache | Nicht versprechen |
|---|---|---|---|
| Sandbox | Hypothesen und Risiken isoliert prüfen | validate, explore, prove feasibility | Produktionsreife |
| Development | reproduzierbar implementieren | build, configure, automate | repräsentative Last oder Daten |
| Integration/Test | Zusammenspiel und Verträge prüfen | verify contracts, failure handling, compatibility | vollständige Produktionsähnlichkeit |
| Staging | Release- und Betriebsbereitschaft nachweisen | promote, rehearse, approve readiness | absolut identische Produktion |
| Production | realen Geschäftswert sicher liefern | release, observe, operate, recover | risikofreien Betrieb |
Merksatz: Eine Umgebung wird nicht durch ihren Namen definiert, sondern durch Zweck, Daten, Zugriffsmodell, Automatisierungsgrad und die Risiken, die dort nachgewiesen werden sollen.
Projektphase 16
Observability and operational stabilityGözlemlenebilirlik ve operasyonel kararlılık
Logs, metrics, traces, SLI/SLO, alerts, and capacity data are made actionable for operation and diagnosis.
Logs, Metriken, Traces, SLI/SLO, Alerts und Kapazitätsdaten werden für Betrieb und Diagnose nutzbar gemacht.
Loglar, metrikler, trace'ler, SLI/SLO, alarmlar ve kapasite verileri işletim ve teşhis için kullanılabilir hale getirilir.
| English | Deutsch | Türkçe |
|---|---|---|
| We cannot operate what we cannot observe. | Was wir nicht beobachten können, können wir nicht zuverlässig betreiben. | Gözlemleyemediğimiz bir sistemi güvenilir şekilde işletemeyiz. |
| The alert should describe an actionable condition. | Der Alarm soll einen konkreten Handlungsbedarf anzeigen. | Alarm uygulanabilir bir durumu göstermelidir. |
| A dashboard is useful only when it supports a decision. | Ein Dashboard ist nur nützlich, wenn es eine Entscheidung unterstützt. | Bir dashboard ancak karar vermeyi destekliyorsa faydalıdır. |
Projektphase 17
Incident response, analysis, and recoveryOlay müdahalesi, analiz ve kurtarma
During an incident, stabilization comes first; root-cause analysis and sustainable actions follow based on evidence.
Während eines Incidents wird zuerst stabilisiert; Ursachenanalyse und nachhaltige Maßnahmen folgen faktenbasiert danach.
Bir olay sırasında önce sistem kararlı hale getirilir; kök neden analizi ve kalıcı önlemler kanıta dayalı olarak ardından gelir.
| English | Deutsch | Türkçe |
|---|---|---|
| First, we stabilize the system. Root-cause analysis follows afterward. | Zuerst stabilisieren wir das System. Die Ursachenanalyse folgt anschließend. | Önce sistemi kararlı hale getiriyoruz. Kök neden analizi daha sonra yapılır. |
| We should distinguish between the trigger and the underlying cause. | Wir sollten zwischen Auslöser und zugrunde liegender Ursache unterscheiden. | Tetikleyici ile temel nedeni ayırmalıyız. |
| The incident review is blameless and action-oriented. | Die Incident-Nachbesprechung ist schuldzuweisungsfrei und maßnahmenorientiert. | Olay değerlendirmesi suçlayıcı değil, aksiyon odaklıdır. |
Projektphase 18
Evolution and modernizationGelişim ve modernizasyon
Architecture decisions are revisited as requirements, load profiles, risks, and technical debt evolve.
Architekturentscheidungen werden anhand neuer Anforderungen, Lastprofile, Risiken und technischer Schulden regelmäßig überprüft.
Gereksinimler, yük profilleri, riskler ve teknik borç değiştikçe mimari kararlar yeniden değerlendirilir.
| English | Deutsch | Türkçe |
|---|---|---|
| The architecture must evolve with the business. | Die Architektur muss sich mit dem Geschäft weiterentwickeln. | Mimari iş gereksinimleriyle birlikte gelişmelidir. |
| We should define criteria for revisiting this decision. | Wir sollten Kriterien für eine erneute Bewertung dieser Entscheidung festlegen. | Bu kararı yeniden değerlendirmek için kriterler belirlemeliyiz. |
| Modernization should reduce risk, not merely replace technology. | Modernisierung soll Risiken reduzieren und nicht nur Technologien ersetzen. | Modernizasyon yalnızca teknolojiyi değiştirmek değil, riski azaltmak için yapılmalıdır. |
Projektphase 19
Communication with different rolesFarklı rollerle iletişim
The same architecture topic is expressed with different levels of detail for engineering, product, security, operations, and management.
Dasselbe Architekturthema wird für Entwicklung, Product, Security, Betrieb und Management mit unterschiedlicher Detailtiefe formuliert.
Aynı mimari konu; geliştirme, ürün, güvenlik, operasyon ve yönetim için farklı ayrıntı seviyelerinde ifade edilir.
| English | Deutsch | Türkçe |
|---|---|---|
| For engineers: the synchronous dependency increases latency and reduces resilience. | Für Entwickler: Die synchrone Abhängigkeit erhöht die Latenz und reduziert die Resilienz. | Geliştiriciler için: Senkron bağımlılık gecikmeyi artırır ve dayanıklılığı azaltır. |
| For management: this dependency increases outage risk and may slow customer-facing processes. | Für das Management: Diese Abhängigkeit erhöht das Ausfallrisiko und kann kundennahe Prozesse verlangsamen. | Yönetim için: Bu bağımlılık kesinti riskini artırır ve müşteri süreçlerini yavaşlatabilir. |
| Adapt the vocabulary, but do not hide the consequence. | Passen Sie die Wortwahl an, aber verschleiern Sie nicht die Konsequenz. | Kullandığınız dili uyarlayın, ancak sonucu gizlemeyin. |
Unterkapitel 19.1
Meeting language and architecture questionsToplantı dili ve tipik mimari sorular
Architecture discussions do not start with a favorite solution. They structure the problem, assumptions, quality goals, options, risks, and the evidence required.
Architektengespräche beginnen nicht mit einer Lieblingslösung. Sie strukturieren Problem, Annahmen, Qualitätsziele, Optionen, Risiken und den erforderlichen Nachweis.
Mimari görüşmeler tercih edilen bir çözümle başlamaz. Problem, varsayımlar, kalite hedefleri, seçenekler, riskler ve gerekli kanıt sistematik biçimde ele alınır.
EN: What problem are we solving, and how will we know that it is solved?
DE: Welches Problem lösen wir, und woran erkennen wir, dass es gelöst ist?
TR: Hangi problemi çözüyoruz ve çözüldüğünü nasıl anlayacağız?
EN: Which assumptions are critical, and how can we validate them early?
DE: Welche Annahmen sind kritisch, und wie können wir sie früh validieren?
TR: Hangi varsayımlar kritik ve bunları erken nasıl doğrulayabiliriz?
EN: Where is the responsibility boundary, and who owns the data?
DE: Wo liegt die Verantwortungsgrenze, und wer besitzt die Datenhoheit?
TR: Sorumluluk sınırı nerede ve verinin sahibi kim?
EN: Which quality attribute is most important under this workload?
DE: Welches Qualitätsmerkmal ist unter diesem Lastprofil am wichtigsten?
TR: Bu yük profili altında hangi kalite niteliği en önemlidir?
EN: What do we gain, what do we give up, and who carries the operational cost?
DE: Was gewinnen wir, worauf verzichten wir, und wer trägt den Betriebsaufwand?
TR: Ne kazanıyoruz, nelerden vazgeçiyoruz ve operasyonel maliyeti kim üstleniyor?
EN: What happens when this dependency is slow, unavailable, or returns inconsistent data?
DE: Was geschieht, wenn diese Abhängigkeit langsam oder nicht verfügbar ist oder inkonsistente Daten liefert?
TR: Bu bağımlılık yavaşsa, kullanılamıyorsa veya tutarsız veri döndürüyorsa ne olur?
EN: Is this decision reversible, and which trigger requires us to revisit it?
DE: Ist diese Entscheidung reversibel, und bei welchem Auslöser müssen wir sie erneut prüfen?
TR: Bu karar geri alınabilir mi ve hangi tetikleyici kararı yeniden değerlendirmemizi gerektirir?
EN: What evidence is required before we promote the solution to the next environment?
DE: Welcher Nachweis ist erforderlich, bevor wir die Lösung in die nächste Umgebung überführen?
TR: Çözümü bir sonraki ortama taşımadan önce hangi kanıt gereklidir?
| Situation | Zu ungenau | Professioneller – English | Deutsch | Türkçe |
|---|---|---|---|---|
| Technologiewahl | We use Kafka. | Kafka is an option if independent consumers and asynchronous processing are required; we still need to validate ordering, delivery semantics, and operational ownership. | Kafka ist eine Option, wenn unabhängige Consumer und asynchrone Verarbeitung benötigt werden; Reihenfolge, Zustellsemantik und betriebliche Verantwortung müssen wir noch validieren. | Bağımsız tüketiciler ve asenkron işleme gerekiyorsa Kafka bir seçenektir; sıralama, teslim semantiği ve operasyonel sorumluluğu ayrıca doğrulamalıyız. |
| Sandbox | First, we create a sandbox. | First, we provision an isolated sandbox to test the highest-risk assumptions and define measurable exit criteria. | Zunächst stellen wir eine isolierte Sandbox bereit, um die risikoreichsten Annahmen zu prüfen und messbare Exit-Kriterien festzulegen. | Öncelikle en riskli varsayımları sınamak ve ölçülebilir çıkış kriterleri belirlemek için izole bir sandbox ortamı hazırlıyoruz. |
| Skalierung | This scales better. | This option can improve horizontal scalability under the expected workload, but it adds coordination and operational complexity. | Diese Option kann unter dem erwarteten Lastprofil die horizontale Skalierbarkeit verbessern, erhöht jedoch Koordinations- und Betriebsaufwand. | Bu seçenek beklenen yük altında yatay ölçeklenebilirliği artırabilir, ancak koordinasyon ve operasyonel karmaşıklık getirir. |
| Review | Looks good. | The proposal satisfies the documented constraints; the open risks are recovery time, migration rollback, and ownership of alerts. | Der Vorschlag erfüllt die dokumentierten Rahmenbedingungen; offen sind Wiederherstellungszeit, Migrations-Rollback und Alert-Verantwortung. | Öneri belgelenen kısıtları karşılıyor; açık riskler kurtarma süresi, migration rollback ve alarm sahipliğidir. |
Meeting-Regel: Eine gute Architekturfrage zwingt nicht zu einer bestimmten Technologie. Sie macht Entscheidungsgrundlage, Risiko oder Nachweis sichtbar.
Unterkapitel 19.2
Role dialogues and architecture reviewsRol diyalogları ve mimari incelemeler
Kommunikationsprinzip: Dieselbe Architekturentscheidung wird je nach Rolle anders erklärt. Die Aussage bleibt fachlich gleich; Detailtiefe, Nutzenbezug und Risikosprache ändern sich.
Architect: The service may publish the event only after the local transaction commits. How will you guarantee idempotent processing?
Architekt: Der Service darf das Ereignis erst nach erfolgreichem Commit der lokalen Transaktion veröffentlichen. Wie stellst du idempotente Verarbeitung sicher?
Mimar: Servis olayı yalnızca yerel işlem başarıyla tamamlandıktan sonra yayımlayabilir. İdempotent işlemeyi nasıl garanti edeceksin?
Entwickler: Wir verwenden einen stabilen Ereignisschlüssel, speichern verarbeitete IDs und testen Wiederholungszustellungen.
Architect: The asynchronous flow improves resilience, but the business status may be delayed for a few seconds. Is that acceptable for this process?
Architekt: Der asynchrone Ablauf erhöht die Ausfallsicherheit, der fachliche Status kann jedoch einige Sekunden verzögert sein. Ist das für diesen Prozess akzeptabel?
Mimar: Asenkron akış dayanıklılığı artırır; ancak iş durumu birkaç saniye gecikebilir. Bu süreç için kabul edilebilir mi?
Product Owner: Ja, sofern der Nutzer den Bearbeitungsstatus sieht und keine Bestellung verloren geht.
Architect: Before go-live, we need ownership for alerts, a tested rollback, and capacity thresholds for the consumer group.
Architekt: Vor dem Go-live benötigen wir klare Alert-Verantwortung, einen getesteten Rollback und Kapazitätsschwellen für die Consumer-Gruppe.
Mimar: Canlıya geçmeden önce alarm sahipliği, test edilmiş geri dönüş ve tüketici grubu için kapasite eşikleri gereklidir.
Plattformteam: Wir dokumentieren Ownership und Runbook und führen den Recovery-Test in Staging durch.
Architect: Which threat does this control mitigate, what evidence is required, and what residual risk remains?
Architekt: Welche Bedrohung reduziert diese Kontrolle, welcher Nachweis ist erforderlich und welches Restrisiko bleibt?
Mimar: Bu kontrol hangi tehdidi azaltır, hangi kanıt gereklidir ve hangi artık risk kalır?
Security: Kurzlebige Tokens reduzieren Missbrauch nach Diebstahl; wir benötigen Ablauf- und Widerrufstests.
Architect: The managed platform reduces operational risk and delivery time, but increases recurring cost and vendor dependency.
Architekt: Die Managed Platform reduziert Betriebsrisiko und Lieferzeit, erhöht jedoch laufende Kosten und Anbieterabhängigkeit.
Mimar: Yönetilen platform operasyonel riski ve teslim süresini azaltır; ancak sürekli maliyeti ve sağlayıcı bağımlılığını artırır.
Management: Bitte quantifizieren Sie Kosten, Ausstiegsoption und den erwarteten Zeitgewinn.
Architect: First we stabilize the service and limit customer impact. Root-cause analysis starts after recovery.
Architekt: Zuerst stabilisieren wir den Service und begrenzen die Kundenauswirkung. Die Ursachenanalyse beginnt nach der Wiederherstellung.
Mimar: Önce servisi kararlı hale getirip müşteri etkisini sınırlarız. Kök neden analizi kurtarmadan sonra başlar.
Incident Lead: Aktuelle Priorität ist Mitigation; Hypothesen werden als unbestätigt markiert.
Vor Sandbox oder Implementierung.
Vor verbindlicher Schnittstellenfreigabe.
Vor produktionsnaher Freigabe.
Vor Staging-Abnahme und Go-live.
Unmittelbar vor Produktionsfreigabe.
Nach Stabilisierung und Datensicherung.
| Situation | Unpräzise | Professionell |
|---|---|---|
| Review-Freigabe | Sieht gut aus. | Die Lösung erfüllt die dokumentierten Anforderungen; offen bleiben Recovery-Zeit und Alert-Ownership. Die Freigabe erfolgt unter diesen dokumentierten Bedingungen. |
| Security | Das ist sicher. | Die identifizierten Bedrohungen werden durch dokumentierte Kontrollen reduziert; das verbleibende Restrisiko ist bewertet und akzeptiert. |
| Go-live | Wir können deployen. | Deployment, Monitoring und Recovery sind getestet; die offenen Risiken liegen innerhalb der vereinbarten Akzeptanzgrenzen. |
Review-Regel: Ein Review endet nicht mit Zustimmung oder Ablehnung, sondern mit Befund, Risiko, Entscheidung, Bedingungen, Verantwortlichen und erneutem Prüfzeitpunkt.
Vertiefung
Interactive self-trainingEtkileşimli öz çalışma
Die Übungen verwenden ausschließlich Formulierungen und Entscheidungsprinzipien dieses Lernkapitels. Der Fortschritt bleibt lokal im Browser und kann jederzeit gelöscht oder vollständig deaktiviert werden.
Welche Aussage beschreibt Problem, Nutzen und Trade-off am präzisesten?
Welche Aussage ist fachlich korrekt?
Welche Management-Formulierung beschreibt dieselbe Konsequenz wie „tight synchronous coupling increases latency and reduces resilience“?
Bringe die Schritte in die fachlich sinnvolle Reihenfolge.
Abschlussregel: Gute Architektensprache macht Annahmen, Entscheidungstreiber, Trade-offs, Risiken, Nachweise und Verantwortlichkeiten sichtbar. Sie ersetzt technische Genauigkeit nicht, sondern übersetzt sie für den jeweiligen Adressaten.