Strategic DDD etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster
Strategic DDD etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster

Türkiye'de Alan Odaklı Tasarım (DDD) ile Devlet Yönetimi



Bir Örnek Senaryo

Giriş:

Alan Odaklı Tasarım (DDD), karmaşık sistemleri yönetmek için kullanılan bir yazılım geliştirme metodolojisidir. DDD, karmaşıklığı, birbirleriyle net sınırları ve etkileşimleri olan alanlara bölerek ele alır. Bu, sistemlerin daha modüler, anlaşılabilir ve sürdürülebilir olmasını sağlar.

devlet yönetiminde DDD'nin kullanımı, daha etkin ve şeffaf bir yönetim anlayışının gelişmesine katkıda bulunabilir.

Stratejik DDD:

Stratejik DDD, bir organizasyonun genel stratejisini ve vizyonunu DDD ilkelerine göre tasarlamayı içerir. Bu aşamada, devlet yönetiminin temel amaçları ve hedefleri belirlenir ve bu hedeflere ulaşmak için gerekli alanlar tanımlanır.

Örnek:

Amaç: Vatandaşların refahını ve yaşam kalitesini artırmak.

Hedefler: Eğitime erişimi kolaylaştırmak, sağlık hizmetlerini iyileştirmek, altyapıyı geliştirmek, iş imkanları yaratmak.

Alanlar: Eğitim, sağlık, altyapı, ekonomi.

Taktiksel DDD:

Taktiksel DDD, her alan için somut modeller ve uygulamalar geliştirmeyi içerir. Bu aşamada, her alanın temel unsurları (varlıklar, değer nesneleri, kök varlıklar), bunların arasındaki ilişkiler ve bu ilişkileri yöneten servisler tanımlanır.

Örnek:

Eğitim Alanı:

Varlıklar: Öğrenci, öğretmen, ders, okul.

Değer Nesneleri: Ders kredisi, not, diploma.

Kök Varlık: Öğrenci.

Servisler: Öğrenci Kaydı, Ders Kaydı, Not Girişi.

Sağlık Alanı:

Varlıklar: Hasta, doktor, hastane, reçete.

Değer Nesneleri: Randevu, teşhis, sigorta bilgisi.

Kök Varlık: Hasta.

Servisler: Hasta Kaydı, Randevu Alma, Teşhis Koyma.

Altıgen Mimari:

Altıgen mimari, DDD'de kullanılan bir yazılım mimarisi modelidir. Bu modelde, her alan kendi servisleri tarafından yönetilir ve diğer alanlarla doğrudan etkileşime girmez. Bu, sistemin daha modüler ve bağımsız olmasını sağlar.

Örnek:

Eğitim Alanı: Eğitim Bakanlığı, kendi servisleri aracılığıyla öğrenci kayıtları, ders kayıtları ve not girişleri gibi işlemleri yönetir. Diğer alanlar (sağlık, altyapı, ekonomi) Eğitim Bakanlığı'nın servislerini kullanarak eğitimle ilgili verilere erişebilir ve bu verileri işleyebilir.

DDD'nin Faydaları:

Daha iyi iletişim: DDD, farklı paydaşlar arasında ortak bir dil oluşturarak daha iyi iletişim kurulmasını sağlar.

Daha modüler sistemler: DDD, sistemlerin daha modüler ve bağımsız olmasını sağlayarak değişikliklerin yapılması ve yeni özellikler eklenmesi kolaylaşır.

Daha sürdürülebilir sistemler: DDD, sistemlerin daha iyi anlaşılabilir ve sürdürülebilir olmasını sağlayarak uzun vadede bakım masraflarının düşmesine katkıda bulunur.

Sonuç:

DDD, Türkiye'de devlet yönetimini daha etkin ve şeffaf hale getirmek için kullanılabilecek güçlü bir araçtır. DDD'nin stratejik ve taktiksel ilkelerini kullanarak, farklı paydaşlar arasında ortak bir dil oluşturmak, daha modüler ve sürdürülebilir sistemler geliştirmek ve vatandaşlara daha iyi hizmetler sunmak mümkün olabilir.

Domain driven design detaylı anlatım, örnek senaryo, interview soruları ve cevapları



Domain-Driven Design (DDD) yazılım geliştirmede karmaşık ihtiyaçları modellemek için bir yaklaşımdır. DDD, genellikle büyük ve karmaşık iş alanları üzerinde çalışan büyük yazılım projelerinde kullanılır. DDD'nin ana prensipleri arasında iş süreçlerini ve uygulamanın işlevlerini anlama ve işlevsel ihtiyaçları çözecek yazılım modelleri oluşturma bulunur.

Domain-Driven Design'in en önemli unsurlarını aşağıdaki şekilde sıralayabiliriz:

1. Ubiquitous Language (Her Yerde Kullanılan Dil): Proje ekibi ve paydaşlar arasında bir dili standart hale getirerek, teknik ve iş terimleri arasında bir çeviri katmanının oluşmasını engeller. Bu dil, tüm ekip tarafından anlaşılabilir ve kullanılır olmalıdır.

2. Domain Model: Domain Model, belirli bir iş alanındaki kavramları ve işlemleri temsil eder. Bu model yazılımın çekirdek bileşenidir ve iş alanındaki entiteleri, değerleri, rolleri, ilişkileri ve işlemleri içerir.

3. Bounded Context: Bounded Context, belirli bir modelin geçerli olduğu bir alanı ifade eder. Her Bounded Context, kendi Ubiquitous Language'ini, kendi modellerini ve kurallarını içerir.

4. Context Map: Farklı Bounded Context'leri ve bunlar arasındaki ilişkileri gösterir.

5. Strategic Design: Bir yazılımın yüksek seviye yapısını ve farklı Bounded Context'ler arasındaki etkileşimleri tanımlar.

6. Tactical Design: Domain Model'in gerçekleştirilmesini sağlayan spesifik tasarım desenlerini içerir.

Domain-Driven Design, karmaşık iş alanlarının yazılım modellerine çevrilmesini ve modelin sürekli olarak iş ihtiyaçlarına göre iyileştirilmesini sağlar. DDD, yazılımın işlevsel gereksinimlerine ve iş süreçlerine odaklanarak, projenin başarıya ulaşması için teknik ve iş ekipleri arasında etkili bir iletişim sağlar. DDD'nin amacı, işlevsel ve teknik gereksinimler arasında bir köprü oluşturarak, yazılımın iş hedeflerine daha iyi hizmet etmesini sağlamaktır.

Domain-Driven Design (DDD), karmaşık iş domainlerini daha anlaşılır hale getirme konusunda yardımcı olur. Daha önce belirtildiği gibi, bu tasarım yaklaşımının çeşitli önemli unsurları vardır. Ancak bunları daha iyi anlamak için bazı DDD kavramlarını daha derinlemesine incelemekte fayda vardır.

Bounded Context

Bounded Context, belirli bir modelin veya dilin kullanıldığı belirli bir kapsam veya sınırı ifade eder. Her bağlam, kendi modelini, dilini ve iş kurallarını oluşturur. Bir yazılım çözümü içinde birden fazla Bounded Context olabilir. Örneğin, bir e-ticaret platformunda alışveriş sepeti ve envanter yönetimi farklı Bounded Context'ler olarak düşünülebilir.


Entities ve Value Objects

DDD içinde, domain modelin temel bileşenleri Entities (varlıklar) ve Value Objects (değer nesneleri) olarak ayrılır.

* Entity: Benzersiz bir kimliği olan ve süre boyunca izlenebilen bir nesnedir. Örneğin, bir online alışveriş sisteminde her bir kullanıcı bir Entity olabilir.

* Value Object: Kimliği olmayan ve değişmez (immutable) olan bir nesnedir. Bu nesneler genellikle bir Entity'nin özelliklerini tanımlamak için kullanılır. Örneğin, bir kullanıcının adresi bir Value Object olabilir.

Aggregates

Aggregates, bir veya daha fazla Entity ve Value Object'i bir araya getirir ve bunları tek bir ünite olarak işler. Her Aggregate'in bir Aggregate Root adı verilen bir ana Entity'si vardır. Aggregate, dış dünya ile iletişimi bu Aggregate Root üzerinden sağlar.




Repositories ve Services

* Repositories: Entities ve Aggregates'in kalıcı saklanması ve geri getirilmesi için kullanılır. Repository, genellikle bir veritabanı ile ilişkilidir ve genellikle CRUD (Oluştur, Oku, Güncelle, Sil) operasyonlarını yönetir.

* Services: Entity veya Value Object'in doğal olarak sahip olmadığı işlevleri gerçekleştirir. Genellikle uygulama veya domain hizmetleri olarak adlandırılır.

Domain-Driven Design, karmaşık iş süreçlerini anlamak, modellemek ve uygulamaları bu süreçlere göre tasarlamak için kapsamlı ve güçlü bir araçtır. İyi bir DDD uygulaması, iş süreçlerini yansıtan sağlam, ölçeklenebilir ve bakımı kolay yazılımlar üretir.

Bir iş domaini, bir yazılım çözümünün çözümlemeye çalıştığı belirli bir iş alanını temsil eder. Ancak çoğu zaman, bir iş domaini kendi içinde birçok farklı alt iş alanı (subdomain) içerebilir. Bu alt iş alanlarına subdomain denir ve genellikle ana iş domainine ait belirli işlevleri veya iş süreçlerini temsil ederler.




DDD'de subdomainler genellikle üç ana kategoriye ayrılır:

1. Çekirdek (Core) Subdomain: Bu, işletme için en değerli ve rekabetçi avantaj sağlayan subdomaintir. Bu, işletmenin ana işlevselliğini temsil eder ve genellikle en fazla işlem ve analiz gerektirir. Bu subdomain üzerinde yapılan işler, işletmenin misyonunu ve vizyonunu direkt olarak etkiler.

2. Destekleyici (Supporting) Subdomain: Bu, çekirdek subdomaini destekleyen ancak kendi başına işletme için rekabetçi bir avantaj sağlamayan subdomaintir. Bu subdomain, çekirdek subdomainin işlevselliğini tamamlar veya genişletir.

3. Genel (Generic) Subdomain: Bu, genellikle tüm işletmeler veya uygulamalar için standart olan işlevselliği temsil eder. Örneğin, bir kullanıcının kimlik doğrulaması veya bir ödeme işleminin işlenmesi genellikle genel bir subdomain olarak kabul edilir. Bu tür işlevselliği çözmek için genellikle dış hizmetler veya mevcut çözümler kullanılır.

Bir yazılım çözümünün tasarımında bu subdomainlerin her biri, Bounded Context olarak adlandırılan kendi modellerine sahip olacaktır. Bounded Context, belirli bir subdomaindeki modellerin, kuralların ve iş süreçlerinin birbirleriyle nasıl ilişkili olduğunu tanımlar. Subdomainler ve Bounded Context'ler, karmaşık iş domainlerini daha yönetilebilir ve anlaşılır hale getirerek DDD'nin anahtar bileşenleridir.



DDD de model ne anlama gelir?


Domain-Driven Design'de (DDD) model, belirli bir iş domainini temsil eden ve domainin kavramlarını, kurallarını ve işlemlerini kodla ifade eden bir soyutlamadır.

Bir model, genellikle nesneler, işlemler ve bunların arasındaki ilişkilerden oluşur. İş domainindeki varlıklar, değerler ve olaylar gibi kavramları temsil eden nesneleri içerir. Bunlar genellikle sınıf ve metotlar gibi yazılım bileşenleriyle ifade edilir.

DDD'deki bir modelin amacı, yazılımın karmaşık iş kurallarını ve işlemlerini çözebileceği bir yapı sağlamaktır. Modelin oluşturulması genellikle iş analistleri, domain uzmanları ve yazılım geliştiriciler arasındaki yakın işbirliği gerektirir. Bu işbirliği, iş ihtiyaçlarının ve iş kurallarının yazılım çözümüne doğru bir şekilde aktarılmasını sağlar.

Model oluşturma süreci, aşağıdaki adımları genellikle içerir:

1. Domaini anlama: Yazılım geliştiriciler ve iş analistleri, iş ihtiyaçlarını ve iş kurallarını anlamak için domain uzmanlarıyla birlikte çalışır.

2. Modeli oluşturma: Yazılım geliştiriciler, iş ihtiyaçlarını ve kurallarını temsil eden nesneleri ve işlemleri tanımlar.

3. Modeli uygulama: Yazılım geliştiriciler, tanımlanan modeli kullanarak yazılımı oluşturur.

4. Modeli sürekli güncelleme: İş ihtiyaçları ve kuralları zamanla değişebilir. Bu nedenle, model de bu değişiklikleri yansıtacak şekilde sürekli olarak güncellenmelidir.

Modelleme, yazılım geliştirme sürecinin ayrılmaz bir parçasıdır ve DDD, bu süreci iş kurallarına ve iş süreçlerine dayalı olarak düzenler. Bu, yazılımın iş hedeflerine daha iyi hizmet etmesini sağlar.




Bir model farklı bounded context ler arasında farklı anlamlar taşıyabilir mi? Model bounded context'e özgü müdür?



Evet, aynı model farklı Bounded Context'ler arasında farklı anlamlar taşıyabilir ve genellikle her Bounded Context, kendi modellerini ve kurallarını içerir.

Bir model, belirli bir Bounded Context (sınırlı bağlam) içinde geçerli olan kurallar ve iş süreçleri tarafından tanımlanır. Aynı model farklı Bounded Context'lerde farklı anlamlar ve davranışlar sergileyebilir.

Örneğin, bir e-ticaret sisteminde "Sipariş" modelini düşünelim. "Müşteri Hizmetleri" Bounded Context'inde, bir "Sipariş" modeli, sipariş durumunu takip etmek, müşteri sorularını yanıtlamak gibi özelliklere sahip olabilir. Ancak "Envanter Yönetimi" Bounded Context'inde, "Sipariş" modeli envanteri azaltma ve stok kontrolü gibi farklı işlevlere sahip olabilir.

Her Bounded Context, kendi Ubiquitous Language'ini (her yerde kullanılan dil) kullanır. Bu dil, o bağlamdaki modelin anlaşılmasını ve iş süreçlerinin doğru bir şekilde temsil edilmesini sağlar.

Bu yüzden her Bounded Context özeldir ve kendi modellerini, kurallarını ve iş süreçlerini içerir. Bu, aynı terimlerin farklı bağlamlarda farklı anlamlar taşımasını ve farklı şekillerde uygulanmasını sağlar. Bu yaklaşım, büyük ve karmaşık domainlerin daha yönetilebilir ve anlaşılır hale getirilmesine yardımcı olur.


Event Storming nedir ve DDD için ne anlam ifade eder?





Event Storming, yazılım geliştirme ekiplerinin iş süreçlerini anlamak ve modellemek için kullandıkları bir işbirliği ve keşif tekniğidir. Bu teknik, ekip üyelerinin bir iş domainini ve iş süreçlerini tartışmak, analiz etmek ve görselleştirmek için bir araya gelmelerini içerir.

Event Storming süreci genellikle büyük bir beyaz tahta veya duvar kağıdı ve renkli yapışkan notlar kullanılarak gerçekleştirilir. Her olay (event), bir yapışkan nota yazılır ve sürecin ilerlemesiyle duvara yapıştırılır. Bu olaylar genellikle süreç boyunca ne olduğunu belirten bir eylemle ifade edilir (örn., "Ürün Sepete Eklendi", "Sipariş Verildi" vb.). Ekip üyeleri, iş süreçlerinin nasıl ilerlediğini anlamak ve modellemek için bu olayları düzenler ve gruplar.

Domain-Driven Design (DDD) bağlamında Event Storming, iş domainlerinin ve alt domainlerin anlaşılması ve modellenmesi için önemli bir araçtır. İş süreçlerini anlama ve görselleştirme yeteneği, ekiplerin karmaşık iş domainlerini daha küçük ve yönetilebilir parçalara bölmelerine olanak sağlar.

Event Storming ayrıca, yazılımın iş hedeflerine hizmet edecek şekilde tasarlanmasını ve uygulanmasını sağlar. İş süreçlerinin anlaşılması ve modellemesi, işlevsel gereksinimlerin ve iş kurallarının doğru bir şekilde kodlanmasına yardımcı olur. Bu, yazılımın iş ihtiyaçlarına daha iyi hizmet etmesini ve iş hedeflerine ulaşmasını sağlar.

Sonuç olarak, Event Storming, DDD'nin anahtar bileşenlerinden biridir ve ekiplerin karmaşık iş domainlerini anlamalarına, modellemelerine ve bunlara dayalı olarak etkili yazılım çözümleri oluşturmalarına yardımcı olur.


DDD'yi bir aptala anlatır gibi örnek bir senaryo ile anlatır mısın?


Tabii ki, bazen karmaşık kavramları basitçe anlamak için örnek senaryolar en iyisidir. Şimdi, hayalimizi kullanarak bir oyuncak mağazasına gidelim ve Domain-Driven Design'ı (DDD) bu bağlamda düşünelim.

1. Domain: Oyuncak mağazamızdaki her şeyi temsil eder. Yani bu, müşteriler, çalışanlar, oyuncaklar, ödeme işlemleri vb. gibi unsurları içerir.

2. Subdomains: Mağazanın belirli bölümlerini temsil ederler. Örneğin, "Oyuncak İnventory Yönetimi" bir subdomain olabilir (hangi oyuncakların stokta olduğunu takip eder), "Müşteri İlişkileri" başka bir subdomain olabilir (müşteri sorularını ve şikayetlerini yönetir), "Satış ve Ödeme" ise başka bir subdomain olabilir (ürünlerin satılması ve ödemelerin işlenmesiyle ilgilenir).

3. Bounded Contexts: Bu, her subdomainin kendi 'dilini' ve 'kurallarını' anladığı alanı temsil eder. Örneğin, "Oyuncak İnventory Yönetimi" context'inde 'sipariş' kelimesi, yeni oyuncakların tedarik edilmesi anlamına gelebilir. Ancak, "Satış ve Ödeme" context'inde 'sipariş', bir müşterinin bir oyuncak satın almak istemesi anlamına gelebilir.

4. Entities ve Value Objects: Bu, her bir context'teki kavramları temsil eder. Örneğin, bir 'Oyuncak' bir entity olabilir. Bu oyuncakların rengi, ağırlığı vb. gibi özellikleri ise value objects olabilir.

5. Aggregates: Bunlar, birlikte çalışan entities ve value objects gruplarıdır. Örneğin, bir 'Satış' aggregate'i, bir 'Müşteri' entity'si, bir 'Oyuncak' entity'si ve 'Ödeme Bilgisi' value object'ini içerebilir.

6. Services ve Repositories: Bu, karmaşık işlemleri yürüten ve verileri saklayan/geri getiren bileşenlerdir. Örneğin, bir 'Ödeme Servisi' kredi kartı işlemlerini işleyebilir. Bir 'Müşteri Repository'si ise müşteri bilgilerini saklayabilir ve gerektiğinde geri getirebilir.

Bu şekilde, DDD, büyük ve karmaşık bir sistemi (oyuncak mağazamız) daha küçük, daha yönetilebilir parçalara böler ve her bir parçanın nasıl işlediğini tanımlar. Her bir parça kendi işlerini yürütür, kendi dilini konuşur ve kendi kurallarına uyar, ancak bir araya geldiklerinde, tüm sistem düzgün bir şekilde çalışır ve mağazamızın düzgün işlemesini sağlar. Yani, ödeme işlemleri sorunsuz gerçekleştirilir, oyuncaklar doğru bir şekilde stoklanır ve yönetilir, müşteri soruları ve sorunları hızlı ve etkili bir şekilde çözülür.

DDD, yazılım geliştirme dünyasında benzer bir işlev görür. Belirli bir iş alanındaki karmaşıklığı azaltır, her bir alt domaini (subdomain) kendi Bounded Context'inde yönetir ve bu Context'lerin kendi modelleri, kuralları ve iş süreçlerini tanımlar. Bu yaklaşım, yazılımın daha verimli ve anlaşılır hale gelmesini sağlar, çünkü her bir parça belirli bir işlevi yerine getirir ve belirli bir iş alanına hizmet eder.

Dahası, her Bounded Context kendi dilini konuştuğu için, yazılımın farklı bölümlerini geliştiren ekipler arasındaki iletişim daha verimli hale gelir. Örneğin, "Satış ve Ödeme" ekibi 'sipariş' kelimesini belirli bir şekilde anlar ve kullanırken, "Oyuncak İnventory Yönetimi" ekibi aynı kelimeyi farklı bir anlamda kullanabilir. Bu, her ekibin kendi iş alanında uzmanlaşmasını ve bu alandaki yazılımı daha etkin bir şekilde geliştirmesini sağlar.


DDD interview soruları ve cevapları


1. Soru: Domain-Driven Design (DDD) nedir?
Cevap: Domain-Driven Design (DDD), karmaşık yazılım projelerinin modellenmesine ve tasarlanmasına odaklanan bir yaklaşımdır. DDD, yazılımın iş kurallarını ve süreçlerini temsil eden bir model üzerinde durur. DDD'nin amacı, iş ihtiyaçlarını doğru bir şekilde anlamak ve bu ihtiyaçları etkili bir şekilde kodlamaktır.

2. Soru: Bounded Context nedir ve neden önemlidir?
Cevap: Bounded Context, belirli bir iş domaini veya subdomaini etrafında sınırları belirlenmiş bir modeli ifade eder. Bir Bounded Context içinde, modelin elemanları - terimler, işlemler ve kurallar - özgül bir anlam ve rol taşır. Bounded Context'ler, aynı terimlerin farklı anlamlar taşıyabileceği büyük ve karmaşık domainlerin daha yönetilebilir hale getirilmesine yardımcı olur.

3. Soru: DDD'de Entity ve Value Object arasındaki fark nedir?
Cevap: Entity, sürekli bir kimliği olan ve durumu zaman içinde değişebilen bir nesnedir. Öte yandan, Value Object, kimliği olmayan ve durumu değişmeyen bir nesnedir. Value Object'ler genellikle Entity'lerin özelliklerini tanımlamada kullanılır.

4. Soru: Aggregate nedir?
Cevap: Aggregate, bir veya daha fazla Entity ve Value Object'in bir araya gelmesiyle oluşan bir gruplama birimidir. Aggregate, veri bütünlüğünü ve iş kurallarını koruma görevini üstlenir. Aggregate'in kökünde, genellikle diğer tüm elemanlarla dış dünya arasındaki etkileşimi kontrol eden bir Entity bulunur. Bu Entity'ye Aggregate Root denir.

5. Soru: Ubiquitous Language nedir ve DDD'deki önemi nedir?
Cevap: Ubiquitous Language, bir Bounded Context içinde kullanılan ve modelin elemanlarını tanımlamak için kullanılan ortak bir dildir. Bu dil, yazılım geliştiriciler, domain uzmanları ve diğer tüm ilgili taraflar arasında anlaşılır olmalıdır. Ubiquitous Language'ın amacı, iletişim engellerini aşmak ve modelin doğru bir şekilde anlaşılmasını sağlamaktır.

Bu ve benzeri sorular, bir DDD mülakatında karşınıza çıkabilecek türden sorulardır. Sorular genellikle DDD'nin temel kavramlarını ve uygulama yöntemlerini anladığınızı ölçmeye yöneliktir.

6. Soru: Domain-Driven Design'da "Repository" nedir?
Cevap: Repository, bir Aggregate kökü için koleksiyon benzeri bir arayüz sağlar ve genellikle bir veritabanıyla iletişim kurma görevini üstlenir. Repository'ler, Aggregate'leri depolamak, geri getirmek ve sorgulamak için kullanılır, böylece bu karmaşık operasyonları Domain Model'inden soyutlarlar.

7. Soru: "Context Mapping" nedir?
Cevap: Context Mapping, farklı Bounded Context'ler arasındaki ilişkileri ve etkileşimleri belirlemek ve görselleştirmek için kullanılan bir tekniktir. Bu, her Bounded Context'in kendi modellerine, diline ve iş süreçlerine sahip olduğu ve bu Context'ler arasındaki etkileşimlerin belirlenmesi gerektiği anlamına gelir.

8. Soru: Domain Event nedir ve ne zaman kullanılır?
Cevap: Domain Event, domain'de önemli bir şeyin meydana geldiğini belirten bir olaydır. Bu olaylar genellikle durum değişikliklerini temsil eder ve yayınlandıklarında, diğer parçaların tepki verebileceği veya belirli işlemleri tetikleyebileceği bir sistemde kullanılırlar.

9. Soru: "Anti-Corruption Layer" (Bozulmayı Önleyici Katman) nedir ve ne için kullanılır?
Cevap: Anti-Corruption Layer, farklı modeller veya diller arasında çeviri yaparak bir modelin başka bir modeli 'kirletmesini' veya 'bozmasını' önlemek için kullanılan bir katmandır. Bu katman genellikle, eski bir sistemle yeni bir sistem arasında bir adaptör veya koruyucu olarak kullanılır, böylece eski sistemdeki modelin dil ve kuralları, yeni sistemin modeline sızmaz.

10. Soru: DDD'nin avantajları ve dezavantajları nelerdir?

Cevap: DDD'nin avantajları arasında karmaşık iş süreçlerini ve kurallarını daha iyi anlama, yazılım ve iş süreçleri arasında daha güçlü bir uyum sağlama ve daha kaliteli ve sürdürülebilir yazılım çözümleri geliştirme yer alır. Ancak DDD, eğer projeniz yeterince büyük ve karmaşık değilse aşırı derecede karmaşık ve zaman alıcı olabilir. Ayrıca, DDD'nin başarılı bir şekilde uygulanması genellikle iyi bir domain bilgisi ve uygun tecrübe gerektirir.

11. Soru: Strategic Design ve Tactical Design kavramlarını açıklayabilir misiniz?

Cevap: Strategic Design, domainin daha geniş bir perspektiften anlaşılmasına yardımcı olan DDD'nin bir parçasıdır. Bounded Context'lerin, Context Map'in ve Subdomain'lerin belirlenmesini içerir. Tactical Design ise, daha detaylı ve teknik seviyede olan ve modelin nasıl kodlanacağını belirleyen DDD'nin bir parçasıdır. Entity'ler, Value Objects, Aggregates, Domain Events ve diğer DDD yapılarının uygulanmasını içerir.

12. Soru: DDD ile mikroservisler arasındaki ilişkiyi açıklayabilir misiniz?

Cevap: DDD ve mikroservisler, birbirlerini tamamlarlar. DDD, mikroservislerin tasarımında kullanılabilecek bir yaklaşımdır. Her mikroservis genellikle belirli bir Bounded Context'e karşılık gelir ve bu Bounded Context içerisindeki iş süreçlerini ve kuralları uygular. Bu yaklaşım, mikroservislerin bağımsız olarak geliştirilmesini ve işletilmesini sağlar.

13. Soru: Event Sourcing nedir ve DDD ile nasıl ilişkilidir?

Cevap: Event Sourcing, uygulamanın durumunu, gerçekleşen olaylar (event) dizisi olarak saklama yaklaşımıdır. Bu, belirli bir duruma nasıl ulaşıldığını tam olarak anlama ve durumu geri döndürme (replay) yeteneği sağlar. DDD ile ilişkili olarak, Event Sourcing genellikle Domain Event'lerin modelleme ve işleme şeklini belirler.

14. Soru: DDD projesinde nasıl bir test stratejisi izlemeniz gerektiğini düşünüyorsunuz?

Cevap: DDD projesinde, testlerin hem unit (birim) seviyesinde hem de Bounded Context'ler arası etkileşimleri test eden entegrasyon seviyesinde yapılması önemlidir. Bunun yanı sıra, iş süreçlerini ve kurallarını doğru bir şekilde yansıttığını doğrulamak için işlevsel testlerin yapılması da önemlidir. Aggregates, Domain Services ve Domain Events gibi DDD'nin ana yapıları, genellikle yoğun bir şekilde test edilmelidir.

Bu ve benzeri sorular, daha ileri seviye DDD konularını ve bu konuların belirli senaryolar ve uygulama alanları ile nasıl ilişkilendiğini anlama yeteneğinizi test edebilir.

15. Soru: Domain Service nedir ve ne zaman kullanılır?

Cevap: Domain Service, Entity veya Value Object'in sorumluluk alanına girmeyen, ancak domain ile ilgili bir operasyonu veya işlemi gerçekleştiren bir servistir. Genellikle, iki Entity veya Value Object arasında gerçekleşen etkileşimleri temsil ederler. Domain Service'ler, iş kurallarını içerir ve durum değişikliği sağlarlar.

16. Soru: DDD'deki Specification Pattern'ini açıklayabilir misiniz?

Cevap: Specification Pattern, bir iş kuralını temsil eden bir tasarım kalıbıdır. Bu pattern, bir kuralın doğru olup olmadığını kontrol eden bir method içerir. Bu, karmaşık iş kurallarının daha iyi yönetilmesine yardımcı olur, çünkü her kuralın ayrı bir Specification olarak modellenebileceği ve bu Specification'ların birleştirilebileceği veya yeniden kullanılabileceği anlamına gelir.

17. Soru: DDD'de hangi tür veritabanı kullanılmalı? SQL, NoSQL, veya Event Sourcing gibi?

Cevap: DDD'nin hangi tür veritabanı kullanılacağına ilişkin spesifik bir gerekliliği yoktur. Ancak, seçilen veritabanının, uygulamanın durumunu yönetme ve karmaşık iş kurallarını uygulama yeteneğine sahip olması önemlidir. Geleneksel SQL veritabanları genellikle işlemelere ve tutarlılığa güçlü destek sağlar, NoSQL veritabanları genellikle ölçeklenebilirlik ve esneklik sağlar, ve Event Sourcing, olay tabanlı ve durumu geri döndürme (replay) yeteneği gerektiren uygulamalar için kullanılır.

18. Soru: Factory Pattern, DDD'de nasıl kullanılır?

Cevap: Factory Pattern, karmaşık nesne oluşturma mantığını soyutlamak için kullanılır. DDD'de, genellikle bir Aggregate, Entity veya Value Object oluşturmak için kullanılır. Factory, nesnenin doğru bir şekilde oluşturulmasını ve tüm iş kurallarının başlangıçta yerine getirilmesini sağlar.

19. Soru: DDD'nin nasıl daha etkin bir şekilde uygulanabileceği hakkında ne düşünüyorsunuz?

Cevap: DDD'nin etkin bir şekilde uygulanabilmesi için, domainin derinlemesine anlaşılması ve iş ihtiyaçlarının doğru bir şekilde modellenmesi gerekir. Bu, yazılım geliştiriciler ve iş analistleri, ürün sahipleri ve diğer ilgili taraflar arasında sürekli iletişim ve işbirliği gerektirir. 

20. Soru: DDD'nin diğer yazılım geliştirme yaklaşımlarına göre hangi avantajları vardır?

Cevap: DDD, karmaşık iş problemlerinin çözümünde bir model üzerinde durarak, yazılımın iş süreçlerini ve kurallarını daha doğru bir şekilde yansıtmasını sağlar. DDD, sürekli iletişim ve işbirliği gerektirir, bu da genellikle daha kaliteli ve sürdürülebilir yazılım çözümleri üretir. Ayrıca, model üzerinde durduğu için, DDD çoğu zaman iş ihtiyaçlarına daha uygun bir yazılım çözümü sunar.

21. Soru: Aggregate Design'ında nelere dikkat etmeliyiz?

Cevap: Aggregate tasarımında, her Aggregate'in tek bir Aggregate Root'u olmalı ve tüm dış etkileşimler bu Root üzerinden yapılmalıdır. Aggregate'ler genellikle işlemleri atomik olarak gerçekleştirme sorumluluğuna sahip olduklarından, Aggregate'lerin boyutunu küçük tutmak önemlidir. Ayrıca, Aggregate'lerin aşırı derecede büyük veya karmaşık hale gelmemesi için, sadece birlikte tutarlılık gerektiren nesnelerin aynı Aggregate'de gruplandırılması önemlidir.

22. Soru: Event Storming nedir ve DDD'ye nasıl katkı sağlar?

Cevap: Event Storming, bir iş sürecini veya sistemini anlamak ve modellerini oluşturmak için kullanılan bir atölye (workshop) türüdür. Bu atölye, Domain Event'leri belirlemek ve bunların bir süreç veya sistemde nasıl etkileşime girdiğini anlamak için tasarlanmıştır. Event Storming, genellikle DDD ile birlikte kullanılır, çünkü DDD'nin temel prensipleriyle çok iyi uyuşur ve iş domainini anlamak ve modellemek için etkili bir yöntem sunar.

23. Soru: Domain-Driven Design projenizde hangi zorluklarla karşılaştınız ve bu zorlukları nasıl aştınız?

Cevap: Bu sorunun cevabı kişiye özgü olacaktır ve adayın DDD ile ilgili tecrübesine ve öğrenimine dair detayları açığa çıkaracaktır. Çeşitli zorluklar olabilir, örneğin modelleme, kodlama, işbirliği veya iletişim konularında zorluklar. Adayın bu zorlukları nasıl aştığını ve DDD uygulamasında hangi öğrenmeleri kazandığını anlatması önemlidir.

24. Soru: DDD'de nasıl bir yazılım mimarisi tercih etmelisiniz? Katmanlı mimari, hexagonal mimari, onion mimari gibi hangi tür mimari daha uygundur?

Cevap: DDD ile kullanılacak mimari, projenin gereksinimlerine ve karmaşıklığına bağlı olarak değişir. Her üç mimari stil de DDD ile iyi çalışabilir.

* Katmanlı mimari, genellikle en yaygın ve en anlaşılır olanıdır. Ancak, katmanlar arasında sıkı bağlantıların oluşması ve kodun monolitik hale gelmesi riski vardır.

* Hexagonal mimari (Portlar ve Adaptorler olarak da bilinir), dış bağımlılıklardan soyutlanmış bir domain modeli sağlar. Bu, uygulamanın farklı ortamlarda (örneğin, test ortamında veya gerçek ortamda) tutarlı bir şekilde çalışabilmesini sağlar.

* Onion mimari, katmanlı mimariye benzer ancak domain modelini merkeze alır ve tüm diğer kod parçalarını (örneğin, kullanıcı arayüzü veya veritabanı kodu) domain modeline hizmet eder şekilde organize eder.

25. Soru: DDD projesinde hangi yazılım geliştirme süreçlerini ve uygulamalarını kullanıyorsunuz? Örneğin, Agile, Scrum, TDD, Continuous Integration/Continuous Delivery (CI/CD) gibi?

Cevap: Bu sorunun cevabı, adayın çalışma biçimine ve DDD projelerini nasıl yönettiğine dair fikir verir. DDD genellikle Agile ve Scrum ile iyi bir şekilde uyuşur, çünkü bu süreçler, kullanıcı hikayeleri ve geri bildirim döngüleri üzerinde durarak iş ihtiyaçlarını daha iyi anlamayı sağlar. TDD ve CI/CD gibi uygulamalar da DDD projelerinde sıklıkla kullanılır, çünkü bunlar kaliteli kodun sürekli olarak geliştirilmesini ve dağıtılmasını sağlar.

26. Soru: DDD'ye başlarken hangi kaynakları önerirsiniz?

Cevap: DDD'ye başlarken genellikle "Domain-Driven Design: Tackling Complexity in the Heart of Software" adlı kitap (Eric Evans tarafından yazılmıştır) önerilir. Ayrıca, "Implementing Domain-Driven Design" adlı kitap (Vaughn Vernon tarafından yazılmıştır) ve "Domain-Driven Design Distilled" adlı kitap da kullanışlıdır. İnternet üzerinde çeşitli bloglar, kurslar ve konferans konuşmaları da bulunabilir.

27. Soru: DDD'yi kullanmanın en büyük zorlukları nelerdir?
Cevap: DDD'nin uygulanması, karmaşıklık seviyesi yüksek olan sistemlerde çok etkili olabilir, ancak bu yaklaşımı benimsemek ve uygulamak zor olabilir. İşte bazı zorluklar:

    * İyi bir modelin oluşturulması, iş domaini üzerinde derinlemesine bilgi gerektirir. Bu bilgi genellikle iş analistleri ve diğer iş uzmanları ile yazılım geliştiriciler arasında paylaşılmalıdır.

    * İyi bir model oluşturmak ve sürdürmek sürekli iletişim ve işbirliği gerektirir. Bu süreç, zaman alıcı ve meydan okuyucu olabilir, özellikle büyük ve dağıtılmış ekiplerde.

    * DDD, özellikle başlangıçta, geliştirme sürecini yavaşlatabilir, çünkü iyi bir modelin oluşturulması ve uygulanması zaman alır.

28. Soru: DDD'nin mikroservislerle nasıl entegre olduğunu açıklayabilir misiniz?
Cevap: DDD ve mikroservisler birbirlerini tamamlarlar. Her mikroservis, genellikle belirli bir Bounded Context'e karşılık gelir ve bu Bounded Context içerisindeki iş süreçlerini ve kurallarını uygular. Bu yaklaşım, mikroservislerin bağımsız olarak geliştirilmesini ve işletilmesini sağlar. Ayrıca, mikroservislerin arasındaki etkileşimleri yönetmek için DDD'nin Context Map kavramı kullanılabilir.

29. Soru: DDD projesinde performans ve ölçeklenebilirlik sorunlarıyla nasıl başa çıktınız?
Cevap: Bu sorunun cevabı, adayın DDD projelerinde karşılaştığı özgün zorluklara ve bu zorlukları nasıl aştığına dair anlayış sağlar. Örneğin, aday performansı artırmak için belirli bir veritabanı teknolojisi kullandığını, ya da ölçeklenebilirliği artırmak için belirli bir yazılım mimarisi veya hizmet dağıtım stratejisi kullandığını söyleyebilir.

30. Soru: Domain-Driven Design'ı öğrenirken sizin için en yararlı olan kaynaklar nelerdi?

Cevap: Bu sorunun cevabı, adayın DDD konusunda nasıl öğrendiği ve hangi öğrenme kaynaklarının ona en çok yardımcı olduğu hakkında bilgi sağlar. Cevap, belirli kitaplar, online kurslar, bloglar, podcast'ler veya konferanslar olabilir. Bu, adayın öğrenme stili ve motivasyonu hakkında işe alım görevlisi veya yöneticiye önemli bilgiler sunar.

31. Soru: DDD'nin Agile ve Scrum ile ilişkisi nedir? Bu yöntemleri birlikte nasıl kullanırsınız?

Cevap: DDD, Agile ve Scrum ile birlikte kullanıldığında, projenin başarısına büyük ölçüde katkıda bulunabilir. Agile ve Scrum, müşteri ihtiyaçlarına odaklanmayı ve düzenli olarak işlevsel yazılım teslim etmeyi vurgular. DDD ise iş süreçlerini ve kurallarını derinlemesine anlamayı ve modellemeyi vurgular. Bu nedenle, DDD, Agile ve Scrum ekiplerinin, iş ihtiyaçlarını daha doğru bir şekilde anlamalarını ve karşılamalarını sağlayabilir.

32. Soru: Bir Aggregate Root nedir ve ne zaman kullanılır?

Cevap: Aggregate Root, bir Aggregate'in dış dünya ile tüm etkileşimlerini yöneten bir Entity'dir. Aggregate Root, Aggregate içindeki diğer Entity ve Value Object'lerin tutarlılığını sağlar. Bir Aggregate Root, bir Aggregate'e dışarıdan bir işlem uygulanmak istendiğinde kullanılır. Yani, bir Aggregate'i değiştirmek veya onunla etkileşime geçmek istediğimizde, bu işlemleri her zaman Aggregate Root üzerinden yaparız.

33. Soru: DDD projenizde hangi programlama dili ve teknolojileri kullandınız ve neden bu seçimleri yaptınız?

Cevap: Bu sorunun cevabı, adayın teknoloji seçimlerine ve bu seçimleri nasıl yaptığına dair fikir verir. Aday, belirli bir programlama dili veya teknolojinin, iş gereksinimlerini karşılamak veya DDD prensiplerini uygulamak için en uygun olduğunu düşündüğü için bu seçimleri yapmış olabilir. Ayrıca, adayın belirli bir teknolojiyi tercih etme sebebi, bu teknolojinin ekip üyeleri tarafından bilinmesi veya bu teknolojinin projenin ölçeklenebilirlik veya performans gereksinimlerini karşılaması olabilir.


Domain Driven Design Kimdir? - Barış Velioğlu - Medium

Barış Velioğlu'nun DDD'yi bir kişilik haline getirip karşılıklı konuştuğu makale DDD'yi anlamamızıa yardımcı oluyor. Yazıya buradan ulaşabilirsiniz.Yazının bir kısmı şu şekilde :

"Söyleşimizin ilk bölümünde Domain Driven Design yani nam-ı diğer DDD ile problem çözerken hangi stratejilerden yararlandığı hakkında konuşuyoruz.

Teknolojinin dili olsa da konuşsa dediğiniz oldu mu hiç? Bugün sizlerle birlikte farklı bir şey deneyeceğiz. Teknolojiye konuşması için gerekli olan meziyetleri vererek onunla karşımda bir insan varmışcasına bir söyleşi yapmayı deneyeceğim. Yani DDD’nin bize biraz kendisinden bahsetmesini isteyeceğiz.

Bu söyleşinin sonunda aşağıdaki soruların hepsine cevap bulmuş olacağız.

  • “Ubiquitous Language” nedir? Neden önemlidir?
  • “Driven Design” kavramı ne ifade eder?
  • DDD için “Domain Expert” neden gereklidir?
  • “Bounded Context” nedir? Contextleri bulabilmek için hangi yöntemlerden yararlanılabilir?
  • Domainler neden 3 ayrı başlık (Core, Generic, Supporting) altında değerlendirilir? Hangisine odaklanmalıyız?"

DDD (Domain Driven Design) Özet- İnglizce - Eleonora Ciceri (Slideshare)





DDD - 1 - A gentle introduction to Domain Driven Design




DDD - 2 - Domain Driven Design: Tactical design



DDD - 3 - Domain Driven Design: Event sourcing



DDD - 4 - Domain Driven Design_ Architectural patterns



DDD - 5 - Domain Driven Design_ Repositories

1- Strategic Domain-Driven Design - vaadin.com - Petter Holmström - Çevirsi

"Bu makale dizisinde, Domain Driven Desgin (domaine dayalı tasarım)'ın ne olduğunu ve projenize - veya bir kısmının - projelerinize nasıl uygulanacağını öğreneceksiniz." diyor Petter Holmström. Ben de elimden geldiğince bu yazı dizisini Türkçe'ye çevirmeye çalışacağım. Umarım İngilizce okumada zorluk çeken arkadaşlar için yararlı olur.



Yazı Dizisinin Orjinali
Örnek DDD projesi

Serinin diğer yazıları :
2 - Tactical Domain Driven Design (Taktiksel DDD)
3 - Domain-Driven Design and the Hexagonal Architecture (DDD ve Altıgen Mimari)


1 - Strategic Domain-Driven Design

(Stratejik DDD)

Domaine Dayalı Tasarım (DDD) Eric Evans'ın konuyla ilgili kitabını 2003'te yayınladığından beri var. Birkaç yıl önce veri tutarlılığı sorunları olan bir projeye katıldığımda DDD ile haşır neşir oldum. Veritabanında tekrarlanan veriler ortaya çıktı, bazı bilgiler hiç kaydedilmedi ve her yerde ve her zaman iyimser kilitleme hatalarıyla karşılaşabileceğimi gördüm. Taktiksel DDD tasarımın yapı taşlarını kullanarak bunu çözmeyi başardık.

O zamandan beri Domaine Dayalı Tasarım (DDD)  hakkında daha fazla şey öğrendim ve bunu projelerimde uygun olan yerlerde kullanmaya çalıştım. Bununla birlikte, diğer geliştiricilerle konuştuğum geçtiğimiz yıllarda, birçoğu domaine dayalı tasarım terimini duydu, ancak bunun ne anlama geldiğini bilmiyorlar. Bu makale dizisinde, gördüğüm ve anladığım şekliyle Domaine Dayalı Tasarım (DDD) a kısa bir giriş yapacağım. İçerik büyük ölçüde Eric Evans'ın Domain-Driven Design: Tackling Complexity in the Heart of Software ve Implementing Domain-Driven Design kitaplarına dayanıyor. Ancak her şeyi kendi sözlerimle açıklamaya ve kendi düşüncelerimi, görüşlerimi ve deneyimlerimi de aşılamaya çalıştım.

Makale dizimi okuyarak Domaine Dayalı Tasarım (DDD)  konusunda uzman olmayacaksınız, ancak umarım bu konu hakkında daha fazlasını başka yerlerde okumanız için size ilham verir. Ayrıca Evans ve Vernon'un kitaplarını okumanızı şiddetle tavsiye ediyorum.

Şimdi ilk konuya, yani stratejik Domaine Dayalı Tasarım (DDD) 'a başlayalım.

Domain(Etki Alanı) nedir?

MacBook'umdaki Sözlük uygulamasında domain'in kelime ararsam aşağıdaki tanımı alırım:

[A] n belirli bir hükümdar veya hükümetin sahip olduğu veya kontrol ettiği bölge bölgesi…

  • belirli bir faaliyet veya bilgi alanı ...
- Apple Sözlüğü

Domaine Dayalı Tasarım (DDD) söz konusu olduğunda, bizim ilgilendiğimiz tanımın ikinci kısmıdır. Bu durumda, faaliyet bir organizasyonun yaptığı şeydir ve bilgi, organizasyonun nasıl yaptığıdır. Alan konseptine organizasyonun faaliyetlerini yürüttüğü ortamı da ekleyeceğiz.

Subdomains (Alt alanlar)

Alan kavramı çok geniş ve soyuttur. Daha somut ve elle tutulur hale getirmek için, onu alt alan adı verilen daha küçük parçalara ayırmak mantıklıdır. Bu alt domainleri bulmak her zaman kolay bir şey değildir ve eğer yanlış yaparsanız, bulmacanızdaki parçalar birden bire birbirine tam oturmadığında yolun yarısında sorun yaşayabilirsiniz.

Alt domainleri aramaya başlamadan önce, alt domain kategorileri hakkında düşünmelisiniz. Tüm alt alanlar üç kategoriye ayrılabilir:
  1. Çekirdek alanlar (Core Domains)
  2. Destekleyen alt alanlar (Supporting Subdomains)
  3. Genel alt alanlar (Generic Subdomains)
Bu kategoriler yalnızca alt alan adlarınızı bulmanıza yardımcı olmakla kalmaz, aynı zamanda geliştirme çabalarınızı önceliklendirmenize de yardımcı olur.

Bir organizasyona özel ve diğer organizsasyonlardan farklı kılan şey çekirdek alan adıdır. (core domain) Bir organizsayon, core domnainde olağanüstü derecede iyi olmadan başarılı olamaz (hatta var olamaz). Core domain çok önemli olduğu için, en yüksek önceliği, en büyük çabayı ve en iyi geliştiricileri alması gerekir. Daha küçük alanlar için yalnızca tek bir core domain tanımlayabilirsiniz, daha büyük alanların birden fazla alanı olabilir. Core domain'in özelliklerini sıfırdan oluşturmaya hazırlıklı olmalısınız.

Destekleyen bir alt alan  (Supporting Subdomains), kuruluşun başarılı olması için gerekli olan, ancak core domain kategorisine girmeyen bir alt alan adıdır. Genel değildir çünkü söz konusu organizasyon için hala bir miktar uzmanlaşma gerektirir. Mevcut bir çözümle başlayabilir ve onu ince ayarlayabilir veya özel ihtiyaçlarınıza göre genişletebilirsiniz.

Genel bir alt alan adı  (Generic Subdomains), kuruluşa özel herhangi bir şey içermeyen ancak yine de genel çözümün çalışması için gerekli olan bir alt alan adıdır. Genel alt alan adlarınız için hazır yazılımları kullanmaya çalışarak zamandan ve işten tasarruf edebilirsiniz. Tipik bir örnek, kullanıcı kimliği yönetimi olabilir.

Organizsayonun ne yaptığına bağlı olarak aynı alt alan adının farklı kategorilere girebileceğini belirtmek gerekir. Kimlik yönetimi konusunda uzmanlaşmış bir şirket için kimlik yönetimi core bir alandır. Bununla birlikte, müşteri ilişkileri yönetimi konusunda uzmanlaşmış bir şirket için kimlik yönetimi, generic bir alt alan adıdır.

Son olarak, tüm alt alan adlarının, hangi kategoriye girdiklerine bakılmaksızın genel çözüm için önemli olduğuna dikkat çekmek önemlidir. Bununla birlikte, farklı miktarlarda çaba gerektirirler ve aynı zamanda farklı kalite ve eksiksizlik gereksinimlerine sahip olabilirler.

Misal

Küçük klinikler için bir EMR (Elektronik Tıbbi Kayıtlar) sistemi oluşturduğumuzu varsayalım. Aşağıdaki alt alanları belirledik:

  1. Hasta tıbbi kayıtlarını yönetmek için Hasta Kayıtları(Patient Records) (kişisel bilgiler, tıbbi geçmiş, vb.).
  2. Laboratuvar testleri sipariş etmek ve test sonuçlarını yönetmek için laboratuar(Lab).
  3. Randevuları planlamak için planlama(Scheduling ).
  4. Hasta kayıtlarına (farklı belgeler, röntgen resimleri, taranmış kağıt belgeler gibi) eklenmiş dosyaları depolamak ve yönetmek için Dosya Arşivi (File Archive).
  5. Doğru kişilerin doğru bilgilere erişimini sağlamak için Kimlik Yönetimi (Identity Management).

Şimdi, bu alt alanları nasıl sınıflandırabiliriz? En bariz olanlar, açıkça genel alt alanlar olan dosya arşivi ve kimlik yönetimidir. Peki ya diğerleri? Bu, bu özel EMR sistemini piyasadaki diğerleri arasında öne çıkaran şeyin ne olduğuna bağlıdır.


Bir EMR sistemi kurduğumuz için, hasta kayıtlarının temel bir alan olduğunu varsaymak oldukça güvenlidir. Akıllı ve yenilikçi zamanlama yoluyla tüm kliniklerin daha verimli çalışmasını sağlayan bir sistem oluşturarak pazarı ele alacaksak, o zaman planlama da muhtemelen core bir alandır. Aksi takdirde, supporting bir alt domaindir, belki mevcut bazı planlama motorunun üzerine inşa edilmiştir. Aynı mantık laboratuar alt alanına da uygulanabilir: iş vakamızın önemli bir parçası hasta kayıtları ve laboratuvar arasında kusursuz bir entegrasyon ise, o zaman laboratuvar büyük olasılıkla core bir alandır. Aksi takdirde, supporting bir alt alan adıdır.


Sorunlardan Çözümlere

Bazen "problem domain" olarak adlandırılan domaini bulursunuz. Bu, domainin yazılımın çözeceği sorunları tanımlaması gerçeğinden kaynaklanmaktadır (sonuçta, yazılımın ilk etapta yapılmasının bir nedeni vardır). Vaughn Vernon, bir alanı bir problem alanına ve bir çözüm alanına ayırır. Sorun alanı, çözmeye çalıştığımız iş sorunlarına odaklanır. Alt alanlar bu alana aittir.

Çözüm uzayı (solution space), problem uzayındaki (problem space) problemlerin nasıl çözüleceğine odaklanır. Çözüm uzayı daha somut, daha teknik ve daha fazla ayrıntı içerir. Peki sorunlarımızı çözüme nasıl dönüştüreceğiz?

The Ubiquitous Language (Ortak bir dil).

Bir alan adı için yazılım oluşturabilmek için, alanı tanımlamanın bir yoluna ihtiyacınız vardır. İlişkisel bir veri modeline veya benzer bir şeye sahip olmak yeterli değildir. Sadece şeyleri ve onların ilişkilerini değil, aynı zamanda olaylar, süreçler, iş değişmezleri, şeylerin zaman içinde nasıl değiştiği gibi dinamikleri de tanımlayabilmelisiniz. Domain hakkında hem geliştiricilerinizle hem de domain uzmanlarıyla tartışabilmeniz ve mantık yürütebilmeniz gerekir. İhtiyacınız olan şey, ortak bir dildir.

Ortak dil, hem alan uzmanları hem de geliştiriciler tarafından alanı açıklamak ve tartışmak için sürekli olarak kullanılan bir dildir. Kodun kendisinden ayrı olarak, bu dil, Domaine Dayalı Tasarım (DDD)  sürecinin en önemli çıktısıdır. Dilin büyük bir kısmı, alan uzmanları tarafından halihazırda kullanılmakta olan alan terminolojisidir, ancak alan uzmanlarıyla işbirliği içinde yeni kavramlar ve süreçler icat etmeniz de gerekebilir. Bu nedenle, alan uzmanlarının aktif katılımı, Domaine Dayalı Tasarım (DDD)'ın  başarılı olması için kesinlikle gereklidir. Müşteri alanınızı öğretmek ve ortak  bir dil oluşturmanıza yardımcı olmak için zaman ve çaba harcamakla ilgilenmiyorsa, müşteriyi fikrini değiştirmeye ikna etmeye çalışmalı veya başka bir tasarım yöntemi seçmelisiniz.

Ortak dili çeşitli şekillerde belgeleyebilirsiniz. İyi bir başlangıç noktası, bir terimler sözlüğü oluşturmaktır. İş süreçleri, örn. swimline diyagramları ve akış şemaları. UML, farklı şeyler farklı süreçler boyunca ilerlerken durumun nasıl değiştiğini açıklamak için nesneler ve durum diyagramları arasındaki ilişkiyi tanımlamak için kullanılabilir. Alt alan adları da ortak dilin bir parçasıdır ve hatta farklı alt alanlar için dilin farklı "lehçelerini" tanımlamanız gerekebilir. Ortak dilin bu düzenlemesi alan modelidir ve sonunda çalışma koduna dönüştürülecektir. Başka bir deyişle, alan modeli bir veri modeli veya bir UML sınıf diyagramı ile aynı değildir.

Ortak dilin güzel bir özelliği vardır ve bu size doğru yolda olup olmadığınızı söylemesi. Bir iş kavramını veya sürecini dili kullanarak kolayca açıklayabiliyorsanız, doğru yoldasınız demektir. Öte yandan, kendinizi bir şeyi açıklamakta zorlanırken bulursanız, büyük olasılıkla dilden ve dolayısıyla alan modelinizden bir şeyler kaçırıyorsunuzdur. Bu olduğunda, bir alan uzmanı tutmalı ve eksik parçaları aramalısınız. Hatta mevcut modelinizi tamamen tersine çeviren ve daha önce sahip olduğunuzdan çok daha üstün bir domain modeliyle sonuçlanan bir geliştirmeyle karşılaşabilirsiniz.

Introducing Bounded Contexts(Sınırlı Bağlamlara Giriş)


Kusursuz bir dünyada, yeknesak bir dil ve tek bir alanla ilgili her şeyi açıklayacak bir model olurdu. Ne yazık ki, çok küçük ve basit alanlar dışında durum böyle değil. İş süreçleri birbiri içine geçebilir ve hatta çakışabilir. Aynı kelime farklı anlamlara gelebilir veya farklı kelimeler farklı bağlamlarda aynı anlama gelebilir. Nasıl gördüğünüze bağlı olarak, sorun alanında bir sorunu çözmenin birden fazla yolu olabilir (ve genellikle vardır).

Büyük Birleşik Modeli(Big Unified Model) bulmaya çalışmak yerine, gerçekleri kabul etmeyi seçeriz ve bunun yerine sınırlı bağlamlar(bounded context) denen bir şey sunarız. Sınırlı bağlam, yeknesak dilin belirli bir alt kümesinin veya diyalektinin her zaman tutarlı olduğu alanın ayrı bir parçasıdır. Başka bir deyişle, bölme ve yönetme uyguluyor ve domain modelini açıkça tanımlanmış sınırları olan daha küçük, az çok bağımsız modellere ayırıyoruz. Her sınırlı bağlamın kendi adı vardır ve bu ad yeknesak dilin bir parçasıdır.

Sınırlı bağlamlar ve alt alanlar arasında mutlaka bire bir eşleştirme olması gerekmez. Sınırlı bir bağlam çözüm uzayına ve bir alt domain sorun uzayına ait olduğundan, sınırlı bağlamı birçok olası çözüm arasında alternatif bir çözüm olarak düşünmelisiniz. Dolayısıyla, tek bir alt alan, birden çok sınırlı bağlam içerebilir. Kendinizi tek bir sınırlı bağlamın birden çok alt alanı kapsadığı bir durumda da bulabilirsiniz. Buna karşı bir kural yoktur, ancak bu, alt alanlarınızı veya bağlam sınırlarınızı yeniden düşünmeniz gerekebileceğinin bir göstergesidir.

Kişisel olarak, sınırlı bağlamları ayrı sistemler olarak düşünmeyi seviyorum (örneğin, Java dünyasında ayrı çalıştırılabilir JAR'lar veya konuşlandırılabilir WAR'lar). Bunun mükemmel bir gerçek dünya örneği, her mikroservisin kendi sınırlı bağlamı olarak kabul edilebileceği mikroservislerdir. Ancak bu, tüm sınırlı bağlamlarınızı mikroservisler olarak uygulamanız gerektiği anlamına gelmez. Sınırlı bir bağlam, tek bir monolitik sistem içinde ayrı bir alt sistem de olabilir.

Misal

Önceki örnekteki EMR sistemini ve daha spesifik olarak hasta kayıtlarının temel alanını tekrar gözden geçirelim. Orada ne tür sınırlı bağlamlar bulabiliriz? Şimdi sağlık hizmetleri yazılımı konusunda uzman değilim, bu yüzden sadece birkaçını uyduracağım, ama umarım, temel fikri anlarsınız.

Sistem, hem doktor randevuları hem de fizyoterapi için hizmetleri destekler. Ek olarak, yeni hastalar için mülakat yapılan, fotoğraflarının çekildiği ve bir ilk değerlendirmenin verildiği ayrı bir alıştırma süreci vardır. Bu, core domainde aşağıdaki sınırlı bağlamlara yol açar:


  1. Hastanın kişisel bilgilerini yönetmek için kişisel bilgiler (Personal Information) (isim, adres, mali bilgiler, tıbbi geçmişi, vb.).
  2. Sisteme yeni hastaları tanıtmak için ilk katılım (Onboarding).
  3. Doktorların hastayı muayene ederken ve tedavi ederken kullandıkları Tıbbi Muayeneler (Medical Exams).
  4. Fizyoterapistlerin hastayı muayene ederken ve tedavi ederken kullandıkları fizyoterapi(Physiotherapy).
Çok basit bir sistemde, muhtemelen her şeyi tek bir bağlama sıkıştırırsınız, ancak bu EMR daha gelişmiştir ve sağlanan her hizmet türü için aerodinamik ve optimize edilmiş özellikler sağlar. Ancak, yine de aynı core alt domainindeyiz.

Bağlamlar Arasındaki İlişkiler


Önemsiz olmayan bir sistemde, çok az (varsa) sınırlı bağlam tamamen bağımsızdır. Çoğu bağlamın diğer bağlamlarla bir tür ilişkisi olacaktır. Bu ilişkilerin belirlenmesi sadece teknik olarak (sistemler teknik olarak nasıl iletişim kuracaklar) değil, aynı zamanda nasıl geliştirildikleri (sistemleri geliştiren ekipler birbirleriyle nasıl iletişim kuracaklar) açısından da önemlidir.

Sınırlı bağlamlar arasındaki ilişkileri belirlemenin en basit yolu, bağlamları yukarı akış bağlamları (upstream contexts) ve aşağı akış bağlamları(downstream contexts) olarak sınıflandırmaktır. Bağlamları bir nehrin yanındaki şehirler olarak düşünün. Akış yukarısındaki şehirlerden akan malzemeler aşağıdaki şehirlere ulaşan nehre bir şeyler döküyor. Malzemelerin bir kısmı aşağı havza şehirleri için çok önemlidir ve bu nedenle nehirden geri alırlar. Diğer şeyler zararlıdır ve aşağı havzadaki şehirlere doğrudan zarar verebilir ("pislik yokuş aşağı yuvarlanır").

Yukarı veya aşağı havza olmanın avantajları ve dezavantajları vardır. Bir yukarı akış bağlamı, herhangi bir yönde gelişmesini bir şekilde özgür kılan başka herhangi bir bağlama bağlı değildir. Bununla birlikte, herhangi bir değişikliğin sonuçları aşağı havza bağlamlarında şiddetli olabilir ve bu da, yukarı akış bağlamında kısıtlamalar getirebilir. Aşağı akış bağlamı, yukarı akış bağlamına bağımlılığıyla sınırlıdır, ancak aşağı akış bağlamının geliştiricilerine bir şekilde yukarı akış bağlamının geliştiricilerine göre daha özgür eller veren diğer bağlamları daha aşağı yönde kırma konusunda endişelenmesine gerek yoktur.

Okların aşağı akış bağlamlarından yukarı akış bağlamlarına işaret ettiği bir bağımlılık diyagramı kullanarak veya U ve D rollerini kullanarak ilişkileri grafiksel olarak tanımlayabilirsiniz.



Son olarak, nerede durduğunuza bağlı olarak bir bağlamın aynı anda hem yukarı akış bağlamı hem de aşağı akış bağlamı olabileceğini unutmayın.

Context Maps and Integration Patterns(Bağlam Haritaları ve Entegrasyon Modelleri)


Bağlamlarımızın ne olduğunu ve nasıl ilişkili olduklarını öğrendikten sonra, bunları nasıl bütünleştireceğimize karar vermeliyiz. Bu birkaç önemli soruyu içerir:

  1. Bağlam sınırları nerede?
  2. Bağlamlar teknik olarak nasıl iletişim kuracak?
  3. Bağlamların domain modelleri arasında nasıl harita oluşturacağız (yani yeknesak bir dilden diğerine nasıl çeviri yapıyoruz)?
  4. Yukarı yönde meydana gelen istenmeyen veya sorunlu değişikliklere karşı nasıl korunacağız?
  5. Aşağı akış bağlamlarında sorun yaratmaktan nasıl kaçınacağız?
Bu soruların cevapları bir bağlam haritası (context map) halinde derlenecektir. Bağlam haritası şu şekilde grafiksel olarak belgelenebilir:


Bağlam eşlemesini oluşturmayı kolaylaştırmak için, çoğu kullanım durumu için çalışan bir dizi hazır tümleştirme modeli(integration patterns) vardır. Hangi entegrasyon modelini seçtiğinize bağlı olarak, onu gerçekten kullanışlı hale getirmek için bağlam haritasına ek bilgiler eklemeniz gerekebilir.


Partnership(Ortaklık)


Her iki bağlamdaki ekipler işbirliği yapar. Arayüzler - ne olursa olsunlar - her iki bağlamın geliştirme ihtiyaçlarını karşılayacak şekilde gelişir. Birbirine bağlı özellikler, her iki takıma da mümkün olduğunca az zarar verecek şekilde uygun şekilde planlanır ve programlanır.

Shared Kernel (Paylaşılan Çekirdek)


Her iki bağlam da çekirdek olan ortak bir kod tabanını paylaşır. Çekirdek, herhangi bir ekip tarafından değiştirilebilir, ancak önce diğer ekibe danışılmadan yapılamaz. İstenmeyen yan etkilerin ortaya çıkmadığından emin olmak için, sürekli entegrasyon (otomatik test ile) gereklidir. İşleri olabildiğince basit tutmak için, paylaşılan çekirdek mümkün olduğu kadar küçük tutulmalıdır. Paylaşılan çekirdekte çok sayıda model kodu varsa, bu bağlamların aslında tek bir büyük bağlamda birleştirilmesi gerektiğinin bir işareti olabilir.

Customer-Supplier (Müşteri - Satıcı)

Bağlamlar, yukarı akış-aşağı akış ilişkisi içindedir ve bu ilişki, yukarı akış ekibi tedarikçi ve aşağı akış ekibi müşteri olacak şekilde biçimlendirilir. Bu nedenle, her iki takım da kendi sistemleri üzerinde az çok bağımsız olarak çalışabilse de, yukarı akış ekibinin (tedarikçi) aşağı akış ekibinin (müşteri) ihtiyaçlarını hesaba katması gerekir.

Conformist (Uyumlu Kimse)

Bağlamlar yukarı akış-aşağı akış ilişkisi içindedir. Bununla birlikte, yukarı akış ekibinin, aşağı akış ekibinin ihtiyaçlarını karşılamak için hiçbir motivasyonu yoktur (örneğin, daha büyük bir tedarikçiden bir hizmet olarak sipariş edilebilir). Alt ekip, her ne olursa olsun, üst ekip modeline uymaya karar verir.

Anticorruption Layer (Adaptosyon Katmanı)


Bağlamlar yukarı akış-aşağı akış ilişkisi içindedir ve yukarı akış ekibi, aşağı akış ekibinin ihtiyaçlarını umursamaz. Ancak, yukarı akış modeline uymak yerine, aşağı akış ekibi, aşağı akış bağlamını yukarı akış bağlamındaki değişikliklerden koruyan bir soyutlama katmanı oluşturmaya karar verir. Bu adaptasyon katmanı, aşağı akış ekibinin ihtiyaçlarına en çok uyan bir domain modeliyle çalışmasına olanak tanır ve yine de yukarı akış bağlamıyla bütünleşir. Yukarı akış bağlamı değiştiğinde, adaptasyon katmanının da değişmesi gerekir, ancak aşağı akış bağlamının geri kalanı değişmeden kalabilir. Bu stratejiyi, yukarı akış arayüzündeki değişiklikleri tespit etmek için otomatik testlerin kullanıldığı sürekli entegrasyonla birleştirmek iyi bir fikir olabilir.

Open Host Service


Bir sisteme erişim, açıkça tanımlanmış bir protokol kullanılarak, açıkça tanımlanmış hizmetler tarafından sağlanır. Protokol, ihtiyaç duyan herkesin sisteme entegre olabilmesi için açıktır. Web hizmetleri ve mikroservisler, bu entegrasyon modelinin güzel bir örneğidir. Bu örüntü, bağlamlar ve onları geliştiren takımlar arasındaki ilişkiyi önemsemediği için diğerlerinden farklıdır. open host service modelini diğer modellerden herhangi biriyle birleştirebilirsiniz.


Bu kalıbı kullanırken dikkat edilmesi gereken nokta, protokolü basit ve kararlı tutmaktır. Sistem istemcilerinin çoğu bu protokolden ihtiyaç duyduklarını alabilmelidir. Kalan özel durumlar için özel entegrasyon noktaları oluşturun.

Published Language (Yayın Dili)


Bu, şahsen açıklamakta en zorlandığım entegrasyon modeli. Benim baktığım şekilde, yayınlanan dil, open host servisine en yakın olanıdır ve genellikle bu entegrasyon modeliyle birlikte kullanılır. Sistemin girişi ve çıkışı için belgelenmiş bir dil (örneğin XML tabanlı) kullanılır. Yayınlanan dile uyduğunuz sürece belirli bir kitaplığı veya bir şartnamenin belirli bir uygulamasını kullanmaya gerek yoktur. Yayınlanmış dillerin gerçek dünya örnekleri, matematiksel formülleri temsil eden MathML ve coğrafi bilgi sistemlerinde coğrafi özellikleri temsil eden GML'dir.

Lütfen web hizmetlerini yayınlanan bir dille birlikte kullanmanız gerekmediğini unutmayın. Ayrıca bir dosyanın bir dizine bırakıldığı ve çıktıyı başka bir dosyada depolayan bir toplu iş tarafından işlendiği bir kuruluma sahip olabilirsiniz.

Separate Ways (Ayrı Roller)


Bu entegrasyon modeli, herhangi bir entegrasyon gerçekleştirmemesi açısından özeldir. Yine de, alet çantasında tutulması gereken önemli bir kalıptır ve çok fazla para ve zaman tasarrufu sağlayabilir. İki bağlam arasındaki entegrasyonun yararı artık çabaya değmediğinde, bağlamları birbirinden ayırmak ve bağımsız olarak evrimleşmelerine izin vermek daha iyidir. Bunun nedeni, sistemlerin artık birbirleriyle ilişkili olmadıkları bir noktaya evrilmiş olmaları olabilir. Aşağı akış bağlamının fiilen kullandığı yukarı akış bağlamı tarafından sağlanan (birkaç) hizmet, aşağı akış bağlamında yeniden uygulanır.

Stratejik Domaine Dayalı Tasarım Neden Önemlidir?


Stratejik domaine dayalı tasarımın aslında daha büyük projeler için tasarlandığına inanıyorum, ancak projede DDD'nin başka herhangi bir parçasını kullanmasanız bile, bundan daha küçük projelerde de yararlanabileceğinizi düşünüyorum.

Şahsen benim için stratejik domaine dayalı tasarımın başlıca çıkarımları şunlardır:

  1. Sınırlar getirir. Kapsam sünmesi (Scope creep), tüm hobi projelerimde değişmeyen bir faktördür. Sonunda, üzerinde çalışmak eğlenceden daha kapsamlı hale gelir veya tek başına bitirmek tamamen gerçekçi olmaz. Müşteri projeleri üzerinde çalışırken, bir şeyleri aşırı düşünerek veya aşırı mühendislik yaparak teknik kapsamın sünmesine neden olmamak için çok çalışmam gerekir. Sınırlar - nerede olurlarsa olsunlar - projeyi daha küçük parçalara bölmeme ve doğru zamanda doğru olanlara odaklanmama yardımcı oluyor.
  2. Her durumda çalışan bir süper model bulmamı gerektirmiyor. Stratejik DDD gerçek dünyada, genellikle az çok açıkça tanımlanmış bağlamlarda birçok küçük modelin olduğunu kabul eder. Bu modelleri kırmak yerine kucaklar.
  3. Sisteminizin getireceği değeri ve en büyük değeri elde etmek için çabalarınızın çoğunu nereye koymanız gerektiğini düşünmenize yardımcı olur. Doğru bir şekilde tanımlamanın ve ardından core domaine odaklanmanın büyük bir fark yaratacağı projelerden kişisel deneyime sahibim. Ne yazık ki, stratejik DDD'yi henüz duymamıştım ve hem zaman hem de para israf ettim.

Ayrıca, bu yaklaşımla riskleri tanımlayacak kadar iyi olduğumu da biliyorum: alt alanlar ve sınırlı bağlamlar bulmak adına alt alanlar ve sınırlı bağlamlar bulmak. Sevdiğim yeni bir şey öğrendiğimde, onu gerçek dünyada denemeyi çok isterim. Bu bazen orada olmayan şeyleri aramaya gittiğim anlamına gelebilir. Buradaki önerim, her zaman bir core domain ve bir sınırlı bağlam (bounded context) ile başlamaktır. Domain modellemesini dikkatlice yapıyorum, ek alt domainleri ve sınırlı bağlamlar varsa, sonunda kendilerini ortaya cıkaracaklardır.

Çeviri için izin veren  Petter Holmström'e teşekkürler.


Bonus :

Barış Velioğlu
Domain Driven Design Kimdir?

Rastgele İçerik

DonanımHaber

© tüm hakları saklıdır
made with by templateszoo