Domain Driven Design
Domain Driven Design - Alan Odaklı Tasarım
Karmaşık yazılım sistemlerinin geliştirilme aşamasında ve bu karşmaşık projeler hayata geçtikten sonra uygulamalarımızın sürekliliğini sağlamakta sıkça yaşanan temel problemlere çözümler getirmeye çalışan bir yaklaşımdır. Geliştirilmiş bir teknoloji veya belirli yöntem değildir.
Eric Evans,Tackling Complexity in the Heart of Software adlı kitabında Domain Driven Design'dan bahsetmiş ve karmaşık sistemlerde oluşan problemlerin kaynağının, çoğunlukla domainlere bölünerek ve orada çözülmesi gerektiğini savunmuştur. Bunun da ancak, business tarafı ile teknik tarafın ortak dili konuşmasından ve yaşanılan sorunların doğru bir şekilde anlaşılmasıyla birlikte projenin doğru modellenmesiyle gerçekleşebileceğini ortaya koymuştur. DDD'nin temel mantığı uygulama içerisinde mantıksal olarak birbiriyle en alakalı birimler aynı domainde tutulur. İş kuralları mantıksal olarak domainlere dağıtılır.
Terimler;
* Ubiquitous Language: Projemizde kullanacağımız her servisin domainde bir karşılığı olması gerekiyor. Böylelikle projede yer alan herkes bu ortak dili konuşabilir birbirini anlayabilir olur.
* Bounded Context : mantıksal açıdan birbirleri ile en alakalı olanların biraraya gelerek gruplaştığı ve bu grubun sorumluluklarının net bir şekilde belirlenmiş olduğu yapılar, Bounded Context olarak adlandırılır. Ortak dili konuşmak olarak da adlandırılabilir.
* Aggregate Root (AR) : Birbiri ile alakalı entity lerin bir iş kuralını ya da akışını gerçekleştirmek için bir arada kullanılması durumu, Aggregate olarak tanımlanıyor. Kendi başlarına sadece bir nesne olan entityler DDD de iş paylaşımı içerisinde transactional bir bütünlüğe erişerek Aggregate oluştururlar.
Layered Architecture;
Her katman fotoğrafta belirtildiği katman ile bağlantılı olabilir. Bu husus katmanları ilgisiz şekilde bağlantıda olmasını ve her katamanın kendi görev sorumlulukalarını yerine getirmesini kolaylaştırır. Katmanların içerikleri daha öncede belirtilidği gibi mantıksal olarak birbiriyle en alakalı birimler aynı domainde tutulur. İş kuralları mantıksal olarak domainlere dağıtılır. Katmanlar arayüzlerle tasarlanmalı ve ve katmanlar arası etkileşim bu arayüzler üzerinden olmalıdır.
DDD'nin anlaşılması açısından Katmanların ve içeriğinde neler oluşturulacağının anlaşılması oldukça önemlidir. Bu açıdan kendi porojemde oluşturduğum katman örnekleri ile bu içeriklerini anlatamaya çalışacağım.
Domain Layer:
Bu katman, uygulamanın kalbidir. entities, value objects, domain services and domain events.Varlıklar-entities, değer nesneleri-value object, etki alanı hizmetleri ve etki alanı olaylarından- domain services and domain events oluşur. Domain katmanında iş süreçlerinin simüle edilmesine odaklanılır.
2. Infrastructure Layer:
Teknolojiye özel kararlara odaklanılır amaçtan ziyade implementasyon kısmı ile ilgilenilir.Bu katmanda domainlerin instanceları yaratılabilir.Ancak genellikle repositoryler bu katmanda etkileşim içerisinde olurlar. Veri tabanı, mesajlaşma sistemleri, email servisleri gibi dış servislere erişilen katman olacaktır.
3. Application Layer:
İş süreci kurgularının ele alındığı katmandır. Uygulamanın yetenekleri bu katmanda gözlemlenebilmektedir. Domaine bağlı varlıklar bu katmanda oluşturulur ve bu katman aracılığı ile güncellemeye maruz kalırlar.
4.User Interface Layer:
Bu katman dış sistemlerle etkileşimin sağlanacağı kısımdır. Bu katman bir insan, bir uygulama veya bir mesajın domainin üzerinde oluşturacağı etkilerin giriş kapısı olarak yer almaktadır.
Last updated
