Domain Driven Design

Domain Driven Design - Alan Odaklı Tasarım

Karmaşık yazılım sistemlerinin geliştirilme aşamasında ve bu karmaşı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 bir araya 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, Aggrate olarak tanımlanıyor. Kendi başlarına sadece bir nesne olan Entity'lerin Domain Driven Design(DDD)' de iş paylaşımı içerisinde transactional bir bütünlüğe Aggrate oluştururlar.

Katmanlı Mimari

Her katman fotoğrafta belirtildiği katman ile bağlantılı olabilir. Bu husus katmanları ilgisiz şekilde bağlantıda olmasını ve her katmanın kendi görev sorumluluklarını yerine getirmesini kolaylaştırır. Katmanların içerikleri daha öncede belirtildiği gibi mantıksal olarak birbirleriyle en alakası birimler aynı domainde tutulur. İş kuralları mantıksal olarak domainlere dağıtılır. Katmanlar arayüzlerle tasarlanmalı 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 projemde oluşturduğum katman örnekleri ile bu içeriklerinin anlatmaya çalışacağım.

1.Domain Layer

Bu katman, uygulamanın kalbidir. Entites, value objects, domain services ve domain events. Varlıklar(entities), deper nesneleri(value object), etki alanı hizmetleri ve etki alanı olaylarından domain services ve domain events oluşur. Domain katmanında iş süreçlerinin simüle edilmesine odaklanı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.