Mikro hizmetleri modellemek için etki alanı analizi kullanma
Mikro hizmetlerin en büyük zorluklarından biri, tek tek hizmetlerin sınırlarını tanımlamaktır. Genel kural, bir hizmetin "tek bir şey" yapması gerektiğidir, ancak bu kuralı uygulamaya koymak için dikkatli bir şekilde düşünülmesi gerekir. "Doğru" tasarımı üretecek mekanik bir işlem yoktur. İş etki alanınız, gereksinimleriniz, mimari özellikleriniz (işlevsel olmayan gereksinimler olarak da bilinir) ve hedefleriniz hakkında derin düşünmeniz gerekir. Aksi takdirde, hizmetler arasındaki gizli bağımlılıklar, sıkı bağlantı veya kötü tasarlanmış arabirimler gibi bazı istenmeyen özellikler sergileyen göz kamaştırıcı bir tasarıma sahip olabilirsiniz. Bu makalede, mikro hizmetler tasarlamaya yönelik etki alanı temelli bir yaklaşım gösterilmektedir. Hizmet sınırlarını değerlendirmek, gelişen iş yükleri üzerinde devam eden bir çabadır. Bazen değerlendirme, değişiklikleri karşılamak için ek uygulama geliştirme gerektiren mevcut sınırların yeniden tanımlarıyla sonuçlanır.
Bu makalede çalışan bir örnek olarak insansız hava aracı teslim hizmeti gerçekleştirilir. Senaryo ve ilgili başvuru uygulaması hakkında daha fazla bilgiyi burada okuyabilirsiniz.
Giriş
Mikro hizmetler, veri erişimi veya mesajlaşma gibi yatay katmanlara değil iş özelliklerine göre tasarlanmalıdır. Ek olarak, gevşek kavrama ve yüksek işlevsel uyuma sahip olmalıdırlar. Diğer hizmetlerin aynı anda güncelleştirilmesine gerek kalmadan bir hizmeti değiştirebiliyorsanız mikro hizmetler gevşek bir şekilde birleştirilir . Mikro hizmet , kullanıcı hesaplarını yönetme veya teslim geçmişini izleme gibi tek ve iyi tanımlanmış bir amaca sahipse uyumlu olur. Bir hizmet, etki alanı bilgilerini kapsüllemeli ve bu bilgileri istemcilerden soyutlamalıdır. Örneğin, bir istemci zamanlama algoritmasının ayrıntılarını veya insansız hava aracı filosunun nasıl yönetildiğini bilmeden bir insansız hava aracı zamanlayabilmelidir. Her mikro hizmet için mimari özelliklerinin, sistemin tamamı için tanımlanmadan etki alanı endişeleriyle eşleşmesi için tanımlanması gerekir. Örneğin, müşteriye yönelik bir mikro hizmetin performans, kullanılabilirlik, hataya dayanıklılık, güvenlik, test edilebilirlik ve çevikliğe sahip olması gerekebilir. Arka uç mikro hizmetinin yalnızca hataya dayanıklılık ve güvenliğe sahip olması gerekebilir. Mikro hizmetlerin birbiriyle zaman uyumlu iletişimleri varsa, aralarındaki bağımlılık genellikle aynı mimari özelliklerini paylaşma gereksinimini doğurar.
Etki alanı odaklı tasarım (DDD), iyi tasarlanmış bir mikro hizmetler kümesine giden yolun büyük kısmını katetmenizi sağlayan bir çerçeve sağlar. DDD’nin stratejik ve taktiksel olmak üzere iki farklı aşaması vardır. Stratejik DDD’de sistemin büyük ölçekli yapısını tanımlarsınız. Stratejik DDD, mimarinizin iş özelliklerine odaklanmaya devam ettiğinden emin olmanıza yardımcı olur. Taktiksel DDD ise etki alanı modelini oluşturmak için kullanabileceğiniz bir tasarım desenleri kümesi sağlar. Bu desenler varlıkları, toplamaları ve etki alanı hizmetlerini içerir. Bu taktiksel desenler, hem gevşek bir şekilde eşlenmiş hem de uyumlu mikro hizmetler tasarlamanıza yardımcı olur.
Bu makalede ve sonraki adımda aşağıdaki adımları izleyip İnsansız Hava Aracı Ile Teslimat uygulamasına uygulayacağız:
Uygulamanın işlevsel gereksinimlerini anlamak için işletme etki alanını çözümleyerek başlayın. Bu adımın sonucunda, daha resmi bir etki alanları kümesine dönüştürülebilecek, resmi olmayan bir etki alanı açıklaması elde edersiniz.
Ardından, etki alanının sınırlanmış bağlamlarını tanımlayın. Her sınırlanmış bağlam, genel uygulamanın belirli bir alt etki alanını temsil eden bir etki alanı modeli içerir.
Sınırlanmış bir bağlamda varlık, toplama ve etki alanı hizmetleri tanımlamak için taktiksel DDD desenleri uygulayın.
Uygulamanızdaki mikro hizmetleri tanımlamak için önceki adımdaki sonuçları kullanın.
Bu makalede öncelikle DDD ile ilgili olan ilk üç adımı ele alacağız. Sonraki makalede mikro hizmetleri tanımlayacağız. Ancak, DDD'nin yinelemeli ve devam eden bir süreç olduğunu unutmamak önemlidir. Hizmet sınırları taşla sabitlenmemiştir. Bir uygulama geliştikçe, bir hizmeti birkaç küçük hizmete bölmeye karar vekleyebilirsiniz.
Not
Bu makalede eksiksiz ve kapsamlı bir etki alanı analizi gösterilmeyecektir. Ana noktaları göstermek için örneği kasıtlı olarak kısa tuttuk. DDD hakkında daha ayrıntılı bilgi için Eric Evans’ın bu terimi ilk kez ortaya attığı Domain-Driven Design (Etki Alanı Odaklı Tasarım) kitabını öneririz. Konuyla ilgili bir diğer iyi kaynak ise Vaughn Vernon’un Implementing Domain-Driven Design (Etki Alanı Odaklı Tasarımı Uygulama) kitabıdır.
Senaryo: İnsansız hava aracıyla teslimat
Fabrikam, Inc. tarafından bir insansız hava aracı ile teslimat hizmeti başlatılıyor. Şirket, bir insansız hava aracı filosunu yönetiyor. İşletmeler hizmete kaydolabiliyor ve kullanıcılar teslim edilecek ürünleri almak üzere insansız hava aracı isteğinde bulunabiliyor. Bir müşteri teslim alma zamanladığında, arka uç sistemi bir insansız hava aracı ataması yapıyor ve kullanıcıya tahmini teslimat süresini bildiriyor. Müşteri, teslimat süresince insansız hava aracının konumunu izleyebiliyor ve tahmini varış zamanı sürekli güncelleştiriliyor.
Bu senaryoda nispeten karmaşık bir etki alanı kullanılıyor. İş açısından önemli konular arasında insansız hava araçlarını zamanlama, paketleri izleme, kullanıcı hesaplarını yönetme, geçmiş verileri depolama ve analiz etme yer alıyor. Üstelik, Fabrikam hızla pazara ulaşmak ve daha sonra hızlıca yineleyerek yeni işlev ve özellikler eklemek istiyor. Uygulamanın yüksek bir hizmet düzeyi hedefi (SLO) ile bulut ölçeğinde çalışması gerekiyor. Ayrıca Fabrikam, veri depolama ve sorgulama için sistemin farklı bölümlerinin çok farklı gereksinimlerinin olmasını bekliyor. Bu ölçütlerin tümünü değerlendiren Fabrikam, İnsansız Hava Aracı ile Teslimat uygulaması için bir mikro hizmet mimarisini tercih ediyor.
Etki alanını analiz etme
DDD yaklaşımı kullanmak, her hizmetin işlevsel bir iş gereksinimine doğal bir uyum sağlaması için mikro hizmetler tasarlamanıza yardımcı olur. Kurumsal sınırların veya teknoloji seçimlerinin tasarımınızı dikte etmesine izin verme tuzağından kaçınmanıza yardımcı olabilir.
Herhangi bir kod yazmadan önce, oluşturduğunuz sistemin kuş bakışı görünümüne ihtiyacınız vardır. DDD, iş etki alanını modelleyerek ve bir etki alanı modeli oluşturarak başlar. Etki alanı modeli, işletme etki alanının soyut bir modelidir. Etki alanı bilgilerini ayrıştırır, düzenler ve geliştiricilerle etki alanı uzmanları için ortak bir dil sağlar.
Tüm işletme işlevlerini ve bunların bağlantılarını eşleyerek başlayın. Bu büyük olasılıkla etki alanı uzmanlarının, yazılım mimarlarının ve diğer proje katılımcılarının ortak çabasıyla olacaktır. Belirli bir biçim kullanmanıza gerek yoktur. Bir diyagram çizin veya beyaz tahta üzerinde çizim yapın.
Diyagramı doldurdukça, ayrık alt etki alanlarını belirlemeye başlayabilirsiniz. Hangi işlevler yakından ilişkili? Hangi işlevleri işletme için zorunlu ve hangileri yardımcı hizmetler sunuyor? Bağımlılık grafiği ne? Bu ilk aşama sırasında teknolojilerle veya uygulama ayrıntılarıyla ilgilenmezsiniz. Bununla birlikte, uygulamanın CRM gibi harici sistemlerle, ödeme işlemeyla veya faturalama sistemleriyle nerede tümleştirilmesi gerekeceğini not etmeniz gerekir.
Örnek: İnsansız hava aracı ile teslimat uygulaması
İlk etki alanı analizinden sonra Fabrikam ekibi, İnsansız Hava Aracı Teslimi etki alanını gösteren kaba bir taslak buldu.
- Sevkiyat , işletmenin temeli olduğundan diyagramın merkezine yerleştirilir. Bu işlevselliği etkinleştirmek için diyagramdaki diğer her şey var.
- İnsansız hava aracı yönetimi de işin temelini oluşturur. İnsansız hava aracı yönetimiyle yakından ilgili işlevler arasında insansız hava aracı onarımı ve insansız hava araçlarının ne zaman bakım ve bakım ihtiyacı olduğunu tahmin etmek için tahmine dayalı analiz kullanılması yer alır.
- ETA analizi , teslim alma ve teslim için zaman tahminleri sağlar.
- Üçüncü taraf taşıma , bir paket tamamen insansız hava aracıyla gönderilemiyorsa uygulamanın alternatif ulaşım yöntemleri zamanlamasını sağlayacaktır.
- İnsansız hava aracı paylaşımı , temel işletmenin olası bir uzantısıdır. Şirket belirli saatlerde fazla insansız hava aracı kapasitesine sahip olabilir ve aksi takdirde boşta olacak insansız hava araçlarını kiralayabilir. Bu özellik ilk sürümde olmayacaktır.
- Video izleme , şirketin daha sonra genişletebileceği başka bir alan.
- Kullanıcı hesapları, Faturalama ve Çağrı merkezi , temel işletmeyi destekleyen alt etki alanlarıdır.
Sürecin bu noktasında uygulama veya teknolojiler hakkında hiçbir karar vermediğimize dikkat edin. Alt sistemlerden bazıları dış yazılım sistemleri veya üçüncü taraf hizmetleri içerebilir. Yine de uygulamanın bu sistem ve hizmetlerle etkileşim kurması gerekir, bu nedenle bunları etki alanı modeline dahil etmek önemlidir.
Not
Bir uygulama bir dış sisteme bağımlı olduğunda, dış sistemin veri şemasının veya API'sinin uygulamanıza sızması ve sonuçta mimari tasarımın tehlikeye girme riski vardır. Bu durum özellikle modern en iyi yöntemleri izlemeyen ve karmaşık veri şemaları veya eski API'ler kullanabilen eski sistemlerde geçerlidir. Bu durumda, bu dış sistemler ile uygulama arasında iyi tanımlanmış bir sınır olması önemlidir. Bu amaçla Strangler Fig desenini veya Anti-Corruption Layer desenini kullanmayı göz önünde bulundurun.
Sınırlanmış bağlamları tanımlama
Etki alanı modeli, dünyadaki kullanıcılar, insansız hava araçları, paketler vb. gerçek varlıkların temsillerini içerir. Ancak bu, sistemdeki her parçanın aynı şeyler için aynı temsilleri kullanacağı anlamına gelmez.
Örneğin, insansız hava aracı onarımını ve tahmine dayalı analizi işleyen alt sistemlerin, insansız hava araçlarının bakım geçmişi, kilometre, yaş, model numarası, performans özellikleri vb. gibi birçok fiziksel özelliğini temsil etmeleri gerekir. Ancak bir teslimat zamanlamak istediğinizde bunlar pek işinize yaramaz. Zamanlama alt sisteminin yalnızca bir insansız hava aracının kullanılabilir olup olmadığını ve toplama-teslimat için tahmini varış süresini bilmesi gerekir.
Bu alt sistemlerin her ikisi için tek bir model oluşturmaya çalışırsak bu, gereksiz bir şekilde karmaşık olacaktır. Ayrıca yapılan herhangi bir değişikliğin farklı alt sistemlerde çalışan farklı takımları memnun edecek şekilde belirlenmesi gerekeceğinden, modelin zamanla gelişmesi de zor olacaktır. Bu nedenle aynı gerçek varlığı (bu örnekte bir insansız hava aracı) iki farklı bağlamda temsil eden farklı modeller tasarlamak genellikle daha iyidir. Her model, yalnızca kendine ait belirli bağlamla ilgili özellikleri ve öznitelikleri barındırır.
Sınırlanmış bağlamlar için DDD kavramı burada devreye girer. Sınırlanmış bağlam basit şekliyle etki alanında belirli bir etki alanı modelinin uygulandığı sınırdır. Önceki diyagrama bakarak, çeşitli işlevlerin tek bir etki alanı modelini paylaşıp paylaşamayacağına göre işlev gruplayabiliriz.
Sınırlanmış bağlamların birbirinden yalıtılmış olması şart değildir. Bu diyagramda, sınırlanmış bağlamları bağlayan düz çizgiler, iki sınırlanmış bağlamın etkileşim kurduğu yerleri temsil eder. Örneğin Sevkiyat, müşteriler hakkında bilgi almak için Kullanıcı Hesaplarına ve filodan insansız hava araçları zamanlamak için İnsansız Hava Aracı Yönetimi'ne bağlıdır.
Domain Driven Design (Etki Alanı Odaklı Tasarım) kitabında Eric Evans, bir etki alanı modelinin başka bir sınırlanmış bağlamla etkileşime geçtiğinde bütünlüğünü korumaya yönelik çeşitli desenleri açıklar. Mikro hizmetlerin temel ilkelerinden biri, hizmetlerin iyi tanımlanmış API'ler aracılığıyla iletişim kurmasıdır. Bu yaklaşım Evans'ın Open Host Service ve Published Language olarak adlandırdığı iki desene karşılık gelir. Açık Konak Hizmeti fikri, alt sistemin diğer alt sistemlerin iletişim kurabilecekleri resmi bir protokol (API) tanımlamasıdır. Yayımlanan Dil, API'yi diğer ekiplerin istemci yazmak için kullanabileceği bir biçimde yayımlayarak bu fikri genişletir. Mikro hizmetler için API'ler tasarlama makalesinde, REST API'leri için JSON veya YAML biçiminde ifade edilen dil bağımsız arabirim açıklamalarını tanımlamak için OpenAPI Belirtimi'ni (eski adıyla Swagger) kullanmayı ele alıyoruz.
Bu yolculuğun geri kalanında Sevkiyat sınırlanmış bağlamı üzerinde duracağız.
Sonraki adımlar
Bir etki alanı analizini tamamladıktan sonra bir sonraki adım, etki alanı modellerinizi daha hassas bir şekilde tanımlamak için taktiksel DDD uygulamaktır.