DDD & Microservices

Yiğit Oğuz

15.10.2019

Related Digital Tech Talk

Microservice Mimarisi

Spesifik bir business motivasyonunu, servisler arası independent ve loosely coupled ilişkilerle ele alırken deployment süreçlerindeki riski minimuma indirebiliyoruz.

Geleneksel programlama pratiklerinin aksine, servislerin kendi data ve state’lerinden sorumlu olması yönetilebilirlik gibi bir avantajı bize fazlasıyla sunuyor.

API’ler vasıtasıyla iletişim kurulması ile servisler arası business motivasyonu oldukça izole hale getirebiliyoruz.

En büyük kazanımlardan biri microservise’leri geliştiren ekipler arası technical stack bagımlılığının olmaması.

Organizasyon şemamızı servis güdümlü bir şekilde kırmamıza imkan veriyor olması, IT yönetimi perspektifinde kendimize oldukça sürdürülebilir bir dünya kılar.

Microservice mimari projeksiyon

Microservice mimari projeksiyon

Api Gateway Pattern

Microservice Modelleme

Microservice dünyasındaki en büyük zorluklardan biri servislerin sınırlarını belirlemek ve onları bağımsız kılmaktır. Bir servisi bir iş ile ilişkilendirerek, separation of concern ilkesine analiz süreçlerimizde önem veriyor olmalıyız. Aksi taktirde servisler arasında dependency oluşturarak tight coupling bir koda sahip oluruz.

Bu noktada domain-driven design (DDD) pratikleri hayatımızı oldukça kolaylaştırıyor.

DDD

Karmaşık yazılımların geliştirilme aşamasında ve hayata geçen bu projelerin sürdürülebilirliği noktasında yaşanabilecek problemleri çözmeye odaklanan bir yaklaşımdır.

Microservice’ler, data access ve messaging gibi yatay katmanlar üzerine değil, business yetenekler doğrultusunda design edilmelidir.

Servislerimiz loose coupling ve yüksek seviyede functional cohesion sağlamalıdır.

Bir servise başka bir servisin güncellenmesini gerektirmeksizin release çıkabiliyorsak işler yolunda gidiyor demektir.

Servisimiz domain bilgisini encapsulate ederek client’ları bir çok bilgiden soyutlamalıdır.

Microservice Özelinde DDD Süreçleri

Business domain’in analiz edilebilmesi için uygulamanın functional requirement‘larının analiz edilmesi gerekmektedir.

Mevcut organizasyonel bağımlılık ve sınırlarımızın veya teknoloji seçimlerimizin tasarım kararlarını dikte etmesinden olabildiğince kaçınmamız gerekmektedir. Böylelikle DDD yaklaşımını her bir microservice özelinde doğal bir uyum ile ele alıyor olmanın önünü açacağız.

 

Bu noktada event storming‘ler büyük önem kazanmaktadır.

Event Storming Nedir?

Event Storming, iş süreçlerine odaklandığımız,karmaşık iş geliştirme süreçlerini basitçe analiz etmeye imkan tanıyan bir workshopdur.

Bu noktada bazı sorulara yanıt veriyor olmamız oldukça önemlidir.

  • Hangi fonksiyonlar yakından ilişkilidir?
  • Hangi fonksiyonlar şirket için hayati öneme sahiptir?
  • Yan hizmetler sunan fonksiyonlarımız nelerdir?
  • İşlevler açısından bağımlılık ne durumdadır?

Araya hemen bir kafka koyma, birilerinin bir yere event fırlatması veya schedule servis’lerin 5 dk’da bir çalışacak olması gibi çözümler için acele etmemize gerek yok. Bunlar birer implementasyon detayı.

Vurguyu iş yetenekleri yerine ölçek üzerine yapıyor olmak microservice modelleme sürecinde sık rastlanan hatalardan biridir.

Domain bilgisi üzerinde edineceğimiz tecrübenin ve iş süreçlerinin zamanla olgunlaşacak olması sebebi ile microservice’lerimizi ölçeklemek hemen mümkün olmayacaktır. Doğru ölçek için zamana ihtiyacımız olduğu kaçınılmazdır.

Microservice’lerin sürdürülebilirliği noktasında tasarım oldukça önemlidir. Bu noktada  bounded context pattern önem kazanıyor.

Bounded Context Nedir?

Business kurallar çerçevesinde birbiri ile yakınen ilişkili (logical boundary) kapsamların guruplaşarak sorumluluk sınırlarının bir küme vasıtasıyla ifade edilmesidir.

Sınırların Belirlenmesi

Bounded Context’lerin net bir şekilde belirlenmesi ve akabinde gerçekleşecek development süreçleri ile birlikte ekipler arası bağımsız geliştirme süreçleri adına ortak bir anlayış ortaya çıkar.

Bu süreçler sürdürülebilirliği artırdığı kadar organizasyon şemasınada dogrudan tesir eder. Buna bağlı olarak microservice geliştirme ekiplerinde zaman içerisinde ortak bir dil oluşur. (Ubiquitous Language in Domain-Driven Design)

DDD'de Ubiquitous Language

Made with Slides.com