Item: Learning Domain-Driven Design İnceleme Özeti
Rating: 4

Özet

Yazılım oluşturmak her zamankinden daha zor. Bir geliştirici olarak yalnızca sürekli değişen teknolojik trendleri takip etmek zorunda değilsiniz, aynı zamanda yazılımın arkasındaki iş alanlarını da anlamanız gerekiyor. Bu pratik kitap size iş alanlarını analiz etmek, iş stratejisini anlamak ve en önemlisi yazılım tasarımını iş ihtiyaçlarıyla uyumlu hale getirmek için bir dizi temel model, ilke ve uygulama sağlar. Yazar Vlad Khononov bu kitapta, bu uygulamaların iş mantığının sağlam bir şekilde uygulanmasına nasıl sağladığını ve geleceğe yönelik yazılım tasarımı ve mimarisine nasıl yardımcı olduğunu size göstermektedir.

İnceleme

Parça 1: Strategic Design (Stratjik Tasarım)

Bu parçanın girişinde Domain-Driven Design (DDD) metodolojisinin iki ana parçaya ayrılabileceğinden bahsedilmektedir: Stratejik tasarım ve taktiksel tasarım. DDD’deki stratejik tasarımın "Ne?" ve "Neden?" sorualarına yanıt verdiği, taktiksel tasarımın ise "Nasıl?" sorusuna cevap verdiği anlatılmaktadır. Bu parçada yer alan bölümlerde genel olarak stratejik tasarım kısmından bahsedileceği belirtilmektedir.

Bölüm 1: Analyzing Business Domains (İş Alanlarını Analiz Etmek)

Bu bölüme ilk olarak İş Alanı (Business Domain) kavramının tam olarak ne olduğundan bahsedilmektedir. Daha sonra Alt Alan (Subdomain) kavramı açıklanmakta ve alt alan türleri tek tek ele alınmaktadır. Kitaba göre alt alanlar şu 3 kategoriye ayrılmaktadır:

Temel Alt Alanlar (Core Subdomains)
Genel Alt Alanlar (Generic Subdomains)
Destekleyici Alt Alanlar (Supporting Subdomains)

Yazara göre temel alt alanlar, bir şirketin diğer şirketlerle rekabet edebileceği en temel ve en karmaşık alt alanlardır. Genel alt alanlar ise diğer şirketlerle benzer olan ve herhangi bir inovasyon gerektirmeyen alt alanlardır. Son olarak destekleyici alt alanlar, şirketin işini yine destekleyen, ancak temel alt alanlar gibi şirketin rekabetçilik ilkesine dayanmayan alt alanlardır. Bu açıklamaları yaptıktan sonra yazar bu alt alanları rekabet avantajı (competitive advantage), karmaşıklık (complexity), geçicilik (volatility) ve çözüm stratejisi (solution strategy) açılarından birbirleri ile karşılaştırmaktadır. Karşılaştırmaya göre şu şekilde bir tablo ortaya çıkmaktadır:

Alt Alan Türü	Rekabet Avantajı	Karmaşıklık	Geçicilik	İmplementasyon	Problem
Temel (Core)	Var	Yüksek	Yüksek	Şirket içi geliştirme	İlgi çekici
Genel (Generic)	Yok	Düşük	Düşük	Dışarıdan satın alma	Zaten çözülmüş
Destekleyici (Supporting)	Yok	Düşük	Düşük	Şirket içi/dışı geliştirme	Açık

Bu karşılaştırmalardan sonra alt alanların sınırlarını tanımlamayla ilgili çeştili açıklamalar yapılmakta ve burada birçok örnek kullanılmaktadır. Daha sonra "Gigmaster" ve "BusVNext" isimli iki kurgusal şirket üzerinden alan analizlerinin (domain analysis) nasıl yapılacağı ile ilgili çeşitli örnekler verilmektedir. En son ise Alan Uzmanı (Domain Expert) denilen kişilerin aslında kim oldukları ve ne iş yaptıkları açıklanarak bölüm sonlandırılmaktadır.

Bölüm 2: Discovering Domain Knowledge (Alan Bilgisini Keşfetmek)

Bu bölüme öncelikle iş dünyasındaki yazılım sistemleri ile ilgili çeşitli problemler açıklanarak başlanmaktadır. Bir yazılım çözümünü etkin bir şekilde tasarlamak için bilgiyi keşfetme yolları ve yazılım projelerindeki iletişim mekanizmaları çeşitli örneklerle açıklanmatadır. Daha sonra kitap boyunca neredeyse her yerde karşımıza çıkacak olan Yaygın Dil (Ubiquitous Language) kavramının ne olduğu açıklanmaktadır. Yaygın dil kullanmanın alan uzmanları ve yazılım geliştiriciler arasında nasıl bir fayda sağlayacağı anlatılmaktadır. Bununla ilgili yine çeşitli örneklendirmeler yapılmaktadır. En son ise model kavramı açıklanmakta ve yaygın dlin iş alanlarında bir model olarak kullanıldığından bahsedilmektedir. Yaygın dil ile ilgili çeşitli araçlardan bahsedilip (Gherkin dili gibi) bölüm sonlandırılmaktadır.

Bölüm 3: Managing Domain Complexity (Alanın Karmaşıklığını Yönetmek)

Bu bölümde öncelikle bir telefonla pazarlama şirketinden örnek verilerek yaygın dil modelinin tutarsız kullanımı gösterilmektedir. Daha sonra yine kitabın en önemli kavramlarından biri olan Sınırlı Bağlam (Bounded Context) kavramının ne olduğu açıklanmaktadır. Yazılım tasarımında kullandığınız modellerin sınırlarından, yaygın dilin sınırlı bağlam üzerindeki yerinden ve sınırlı bağlamların kapsamından bahsedilmektedir. Sınırlı bağlam ve alt alan kavramları arasındaki benzerlik ve farklılıklar açıklanmaktadır. Bu iki kavram arasındaki temel farkın şu olduğuna dikkat çekilmektedir: Alt alanlar keşfedilir, sınırlı bağlamlar tasarlanır.

Daha sonra sınırlı bağlam kalıbının bir Domain-Driven Design aracı olduğundan ve yazılım tasarımında, tasarımı iki açıdan sınırlandırdığından bahsedilmektedir: Fiziksel ve sahiplik. Fiziksel sınırlar açısından bir sınırlı bağlamın, bir servis veya proje olarak implement edilip diğer sınırlı bağlamlardan bağımsız olarak dağıtılması ve versiyonlanması gerektiği anlatılmaktadır. Sahiplik açısından ise bir sınırlı bağlamın yalnızca bir takım tarafından üstlenilmesi gerektiği anlatılmaktadır. Bir sınırlı bağlam ile iki farklı takımın çalışamayacağından bahsedilmektedir. Ayrıca takımlar ve sınırlı bağlamlar arasında bu ilişkinin tek yönlü olduğundan ve bir takımın birden fazla bağlam ile çalışabileceğinden de bahsedilmektedir. Bölümün sonunda ise sınırlı bağlamlar ile ilgili gerçek hayattan örnekler verilmektedir.

Bölüm 4: Integrating Bounded Contexts (Sınırlı Bağlamları Entegre Etmek)

Bu bölümde genel olarak sınırlı bağlamlar arasındaki ilişkilerden bahsedilmektedir. Sınırlı bağlamların tamamen bağımsız olmadığından ve birbirleri ile etkileşim içinde olabileceğinden bahsedilmektedir. Yani sınırlı bağlamların birbirlerinden bağımsız bir biçimde gelişebileceğinden, ancak birbirleri ile entegre edilmeleri gerektiğinden bahsedilmektedir. Yazar sınırlı bağlamlar arasındaki bu bağlantılara Kontrat (Contract) adı verildiğinden bahsetmektedir. Bu bölümde genel olarak sınırlı bağlamlar arasındaki ilişkileri ve entegrasyonları tanımlayan tasarım kalıpları 3 kategoride incelenmektedir:

İşbirliği (Cooperation)
Müşteri-Sağlayıcı (Customer-Supplier)
Ayrı Yollar (Separate Ways)

İşbirliği tasarım kalıplarının aralarında iyi kurulmuş ilişkiler bulunan takımlar tarafından implement edilen sınırlı bağlamlar ile ilgili olduğuna dikkat çekilmektedir. En basit tabiriyle bunların tek bir takım tarafından implement edilen sınırlı bağlamlar olduğu söylenmektedir. Bu kategoriye giren iki DDD tasarım kalıbı açıklanmaktadır:

Partnerlik (Partnership)
Paylaşılan Çekirdek (Shared Kernel)

Müşteri-Sağlayıcı tasarım kalıplarında ise bir sınırlı bağlamın servis sağlayıcı, diğer bir sınırlı bağlamın ise bu servisi kullanan bağlam olduğu ifade edilmektedir. İşbirliği kalıplarına göre bu kalıplarda takımların bağımsız olarak çalıştığı vurgulanmaktadır. Müşteri-Sağlayıcı kategorisinde 3 DDD tasarım kalıbı açıklanmaktadır:

Konformist (Conformist)
Bozulma Karşıtı Katman (Anticorruption Layer)
Açık-Host Servisi (Open-Host Service)

Son olarak da Ayrı Yollar tasarım kalıbı kategorisinin ne olduğu, nerede ve ne zaman kullanılabileceği açıklanmakta, genel alt alanlar ile ilişkisi incelenmektedir. Bölümün sonunda ise bir sistemde yer alan sınılı bağlamlar ve onlar arasındaki ilişkilerin gösterimi için kullanılan Context Map diyagramları açıklanmakatdır.

Parça 2: Tactical Design (Taktiksel Tasarım)

Bu parçada "Ne?" ve "Neden?" sorularından ziyade, DDD’de "Nasıl?" sorusuna cevap veren taktiksel tasarım kalıplarından bahsedilmektedir.

Bölüm 5: Implementing Simple Business Logic (Basit İş Mantığı İmplementasyonu)

İş mantığı bir yazılımın en önemli parçasıdır. Bu bölümde basit iş mantığı implementasyonu ile ilgili çeşitli tasarım kalıplarına değinilmektedir. Öncelikle Transactional Script kalıbı anlatılmaktadır. Bu kalıbın nerede, ne zaman ve nasıl kullanılacağından bahsedilmektedir. Daha sonra Active Record kalıbı anlatılmaktadır. Bu kalıbın nasıl implement edilebileceğinden ve nerelerde kullanılması gerektiğinden bahsedilmektedir.

Bölüm 6: Tackling Complex Business Logic (Karmaşık İş Mantığnı Ele Almak)

Bu bölümde ise karmaşık iş mantığı implementasyonunda kullanılan bazı tasarım kalıpları anlatılmaktadır. Bu kalıplar Domain Model isimli bir model üzerinde toparlanmaktadır. Yazara göre bu model 3 ana yapı taşından meydana gelmektedir:

Value Objects: Bu nesneler bir ID’ye ihtiyaç duymazlar. Bu nesneler üzerindeki bir değişiklik yeni bir nesne meydana getireceği için, bu nesnelere değiştirilemez nesneler diyebiliriz. Value Object’ler sadece veri değil aynı zamanda davranış da belirtirler. Value Object’lerdeki değerleri değiştiren metotlar yeni Value Object’ler meydana getirirler.
Aggregates: Parçalanmaz sınırları paylaşan nesnelerin bir hiyerarşisini belirtir. Bir Aggregate’in sınırları içerisinde yer alan bütün veriler iş mantığını implement etmek için fazlaca tutarlı olmalıdırlar. Aggregate’lerin durumu ancak açık arayüz metotları ile komutlar çalıştırılarak değiştirilebilir.
Domain Services: Value Object veya Aggregate kategorisine girmeyen ve durum tutmayan her şey bu kategoriye girer.

Bölüm 7: Modeling the Dimension of Time (Zaman Boyutunu Modellemek)

Bu bölümde iş mantığına zaman ile ilgili şeyler eklendiğinde, Aggregate’leri nasıl kullanabileceğimizle ilgili yöntemler anlatılmaktadır. Bölüm ilk olarak Event Sourcing tasarım kalıbı ile başlamaktadır. Bu kalıba göre olay bazlı bir sistemde arama yapma, analiz yapma, "Source of Truth" ve "Event Store" gibi kavramlar örnekler ile anlatılmaktadır. Daha sonra Aggregate’lere bir yaşam döngüsü kazandıran Event-Sourced Domain Model isimli model anlatılmaktadır. Bu model ile ilgili birçok örnek verilmekte ve avantajları ile dezavantajları anlatılmaktadır. Daha sonra olay bazlı sistemler ile ilgili sıkça sorulan sorular tartışılarak bölüm sonlandırılmaktadır.

Bölüm 8: Architectural Patterns (Mimari Kalıplar)

Bu bölümde bir yazılım mimarisinde yer alan bileşenler ile ilgili çeşitli popüler tasarım kalıpları anlatılmaktadır. Öncelikle iş mantığı ile yazılım mimarisi arasındaki farklar anlatılmaktadır. Daha sonra bölüm boyunca şu 3 kalıp anlatılmaktadır:

Layered Architecture: Bu mimari kalıp kodu teknik olarak parçalara bölmek ile ilgilidir. Bu kalıp Active Record kalıbı ile oldukça uyumludur.
Ports & Adapters: Bu tasarım kalıbı iş mantığını merkeze koyar ve onu bütün altyapısal bağımlılıklardan ayırır. Bu kalıp Domain Model kalıbı ile uyumludur.
Command-Query Responsibility Segregation (CQRS): Bu kalıpta aynı veriler birden çok modelde tutulur. Bu kalıp genellikle Event-Sourced Domain Model kalıbı ile uyumlu olsa da diğer kalıplar ile de rahatlıkla kullanılabilir.

Bölüm 9: Communication Patterns (İletişim Kalıpları)

Bu bölümde daha çok yazılım sisteminde yer alan bileşenlerin iletişimi ile ilgili tasarım kalıpları anlatılmaktadır. Bölüm ilk olarak Anticorruption Layer veya Open-Host Service’leri implement etmek için kullanılabilen model aktarımı ile ilgili tasarım kalıplarına yer vermektedir. Daha sonra ise Aggregate’lerin entegrasyonu ile ilgili şu 3 kalıp açıklanmaktadır:

Outbox: Bu kalıp Aggregate’lerin domain olaylarının aktarımı için güvenli bir yoldur. Domain olaylarının her zaman aktarıldığından emin olur. Bu durum hata alma gibi senaryolarda bile geçerlidir.
Saga: Bu kalıp bileşenler arası basit iş süreçlerini implement etmek için kullanılır.
Process Manager: Bu kalıp ise bileşenler arası daha karmaşık iş süreçlerini implement etmek için kullanılır.

Parça 3: Applying Domain-Driven Design in Practice (DDD’yi Pratikte Uygulama)

Bu parçada genel olarak ilk iki parçada anlatılanlar birleştirilerek pratikte DDD tasarım kalıplarının nasıl uygulanması gerektiği anlatılmaktadır.

Bölüm 10: Design Heuristics (Buluşsal Yöntemleri Tasarlamak)

Bu bölüm, ilk iki parçada anlatılan stratejik ve taktiksel tasarım kalıplarını bir araya getirip hangi durumlarda hangilerinin kullanılması ile ilgili deneysel bir akış diyagramı oluşturmaktadır. Bu akış diyagrmaına göre önce alt alan türüne göre iş mantığı tasarım kalıbı seçilmekte, daha sonra mimari tasarım kalıbı seçilmekte ve en sonunda ise test etme stratejisi belirlenmektedir. Test etme stratejileri de yine bu bölümde anlatılmaktadır. Bu stratejiler şunlardır:

Testing Pyramid: Bu strateji daha çok birim testlerine odaklanır. Daha sonra entegrasyon testlerine ve en son ise End-to-end testlere odaklanır.
Testing Diamond: Bu strateji daha çok entegrasyon testlerine odaklanır. Diğer testlere daha az odaklanır.
Reversed Testing Pyramid: Testing Pyramid stratejisinin tam tersidir. Daha çok End-to-end testlere, ondan sonra entegrasyon testlerine ve en son ise birim testlere odaklanır.

Bölüm 11: Evolving Design Decisions (Tasarım Kararlarının Gelişimi)

Bu bölüm genel olarak iş alanlarındaki değişim ve gelişime bağlı olarak tasarım kalıplarını ve kullanılan mimariyi nasıl değiştirebileceğimiz üzerinde durmaktadır. Anlatılan stratejik ve taktiksel tasarım kalıpları arasında nasıl geçişler yaşanabileceğini ve bu geçişler sırasında ne gibi sorunlarla karşılaşabileceğinizi açıklamaktadır. Ayrıca organizasyonel değişimlerin de bunlara etkisi örneklerle açıklanmaktadır. Alt alanların, sınırlı bağlamların ve Aggregate’lerin büyümesini nasıl ele alacağımız tek tek açıklanmaktadır.

Bölüm 12: EventStorming

Bu bölümde projede yer alan bir grup insanın bir araya gelip beyin fırtınası yöntemiyle tasarım kalıplarına karar vermesini sağlayan EventStorming isimli teknik üzerinde durulmaktadır. EventStroming oturumuna kimlerin katılması gerektiği ve bu oturumdan ne beklenmesi gerektiği üzerinde durulmaktadır. Daha sonra bu oturumda yer alan adımlar başlıklarla incelenmektedir. Bu adımlar şöyledir:

Yapısal olmayan keşif (Unstructured exploration)
Zaman çizelgeleri (Timelines)
Sorunlar (Pain points)
Esas olaylar (Pivotal events)
Komutlar (Commands)
Politikalar (Policies)
Okuma modelleri (Read models)
Dış sistemler (External systems
Kümeleşmeler (Aggregates)
Sınırlı bağlamlar (Bounded contexts)

Bölüm 13: Domain-Driven Design in the Real World (Gerçek Dünyada DDD)

Bu bölümde DDD araçlarını gerçek yaşam senaryolarında nasıl uygulayabileceğimiz anlatılmaktadır. Özellikle eski tasarım ve kodları DDD’ye geçirirken ne gibi sorunlar oluşabileceği ve bunlarla ilgili çözüm stratejilerinden bahsedilmektedir. Yeni başlayan projelerde öncelikle iş alanlarının iyi analiz edilmesi gerektiği, organizasyonun alt alanlarının iyi bir şekilde çıkarılması gerektiği, sorunların düzgün bir şekilde çıkarılması ve değişikliklerin geçişli olarak uygulanması gerektiği anlatılmaktadır.

Parça 4: Relationships to Other Methodologies and Patterns (Diğer Kalıplar ve Metodolojiler ile İlişkiler)

Bu parçada DDD’nin genel olarak diğer metodolojiler ve mimari tasarım kalıplarıyla ilişkisi incelenmektedir.

Bölüm 14: Microservices (Mikroservisler)

Bu bölümde yazar ilk olarak tarihsel olarak DDD ile mikroservislerin birbirleri ile güçlü bağlarının bulunduğunu ve hatta mikroservis ile sınırlı bağlam kavramlarının birbirleri yerine kullanıldığını açıklamaktadır. Bu bölümde genel olarak bu kavramların aynı kavramlar olmadığı üzerinde durulmaktadır. Yazara göre bütün mikroservisler birer sınırlı bağlamdır, ancak bütün sınırlı bağlamlar mikroservis olmak zorunda değildir. Bölüm genel olarak bu iki kavram arasındaki bağlantıyı açıklamakla geçmektedir.

Bölüm 15: Event-Driven Architecture (Olaya Dayalı Mimari)

Bu bölümde olaya dayalı mimari ile DDD arasındaki ilişkiler açıklanmaktadır. Burada olaya dayalı bir sistemde sınırlı bağlamlar arasındaki iletişimde kullanılan 3 olay tipi açıklanmaktadır:

Event Notification: Önemli bir şey olduğunda verilen bildirim olayıdır. Ancak mesajı üreten kısmın, tüketen kısma düzgün bir şekilde anlatabilmesi için, mesajda bazı yerleri açık bir şekilde belirtmesi gerekir.
Event-Carried State Transfer: Mesaj bazlı bir veri kopyalama mekanizmasıdır. Her bir olay, içerisinde üretici tarafın verilerinde kullanılacak durumun (state) o anki görüntüsünü içerir.
Domain Event: Üretici tarafın iş alanındaki bir olayı tanımlayan mesajdır.

Bölüm 16: Data Mesh (Veri Ağı)

Bu bölümde daha çok sistemde çeşitli amaçlar için kullanılan verilerin DDD tasarım kalıpları ile ilişkileri incelenmektedir. Yazar ilk olarak verileri analitik model verileri (OLAP) ve operasyonel model verileri (OLTP) olarak ikiye ayırmakta ve bunlar arasındaki farkları incelemektedir. Daha sonra analitik verileri işlemeye yarayan platformarı tanıtmaktadır. İlk başta tanıtılan iki platform şunlardır:

Data Warehouse: Bu mimari bir sistemin operasyonel tarafından verilerin çıkarılması, kaynak verinin analitik veriye dönüştürülmesi ve bu verilerin veri analizi yapan veritabanlarına yüklenmesi süreçlerini kapsamaktadır.
Data Lake: Data Warehouse mimarisine benzerdir. Ancak bu mimarideki fark, operasyonel verilerin analitik veriye dönüştürülmesinden ziyade, ayrı bir yerde ham olarak turulmasıdır. Böylelikle veriyi kullanan taraflar bu verileri istediği formata kendi dönüştürme yöntemleri ile dönüştürebilirler.

Daha sonra bölüm Data Mesh (Veri Ağı) kavramını açıklayarak devam etmektedir. Bu kavram analitik verilerin DDD yaklaşımı ile ele alınmasını sağlayan bir mimaridir. Data Mesh ile veriler sınırlı bağlamlar ile farklı kategorilere ayrılarak, farklı iş alanlarının onları kolayca kullanması sağlanmaktadır. Böylelikle geleneksel analitik veri işleme yöntemlerinin açıklarını kapatmaktadır.

Değerlendirme

Kitabın anlattığı konuların ilerleyişi ve verdiği örnekler çok iyi olsa da yer yer kitapta yer alan bazı açıklamalar fazla soyut kalmaktadır. Yazar bazı yerlerde diğer yazar ve metodolojistlerin sözlerinden alıntı yapmaktadır. Ancak bu sözler bazen konunun anlaşılmasından çok, daha fazla kafa karışıklığına neden olmaktadır. Bu nedenle kitabın okunabilirliği ve anlaşılabilirliği ortalama seviyededir diyebiliriz.

Kitabın okuyucu kitlesi hali hazırda teknik olarak parçalara ayrılmış bir mimaride çalışan, ancak domain olarak parçalara ayrılmış bir mimariye veya sisteme geçiş yapmak isteyen kişilerdir diyebiliriz. Yani bu kitabın okuyucularının yazılım mimarisi hakkında ön bilgiye sahip olması gerektiğini söyleyebiliriz. Aksi takdirde bazı yerler çok daha anlaşılmaz olacaktır. Ancak yine de bu kitabı okumak için DDD ile çok içli dışlı olmak veya çok fazla bilgiye sahip olmanız gerekmez. Çünkü kitabın amacı zaten DDD yaklaşımını baştan sona ele almaktır.

Kitap 4 parçadan meydana gelmektedir. İlk iki parça genel olarak DDD’deki stratejik ve taktiksel bazı kalıplar üzerinde durmakta ve bunları açıklamaktadır. Üçüncü parçada ise bu tasarım kalıplarını birleştirip pratikte nasıl kullanılacağı ile ilgili anlatımlar yapmaktadır. Asıl vurucu noktanın üçüncü parça olduğunu söyleyebiliriz. Çünkü ilk iki parçada bu tasarım kalıplarından ayrı ayrı bahsettiğinde çok fazla kafanıza oturmayabiliyor. Ancak üçüncü parça anlattıklarını toparlayan bir kısım olmuş. Son parçada ise DDD’nin diğer mimari ve veri tasarım kalıplarında kullanımı anlatılmıştır.

Sonuç olarak, bu kitap farklı alanlarda çalışıp DDD tarafına geçiş yapacak olan yazılımcılar için oldukça iyi bir içeriğe sahiptir. İlk iki parçada yer alan anlatımları birleştirmek zor olsa da üçüncü parça durumu kurtarmıştır. Bu nedenle içerik kalitesi ve eşsizliği anlamında okuyucu kitlesine göre oldukça iyi olduğunu söyleyebiliriz. Görsel kullanımı olarak yeterli düzeydedir. Bence bazı yerlerde yine daha iyi görseller ve diyagramlar tercih edilebilirdi. Verilen örneklerin yine çoğu yerde yeterli olduğunu ama birkaç yerde eksik kaldığını düşünüyorum.

Learning Domain-Driven Design İnceleme Özeti

Tam İsim: Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy
Basım No: 1st Edition
Yazarlar: Vlad Khononov
Yayımlama Tarihi: 16 Kasım 2021
Sayfa Sayısı: 337

Anlaşılabilirlik/Okunabilirlik

Görsel/Diyagram Kullanımı

İçerik Kalitesi/Eşsizliği

Örneklendirme/Örnek Kalitesi

Sonuç Özeti