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 düşünmeniz gerekir. "Doğru" tasarımı üretecek mekanik bir işlem yoktur. İş alanınız, gereksinimleriniz ve hedefleriniz hakkında derinden düşünmeniz gerekir. Aksi takdirde, hizmetler arasındaki gizli bağımlılıklar, sıkı bağlantı veya kötü tasarlanmış arabirimler gibi istenmeyen bazı özellikler sergileyen bir göz kamaştırıcı tasarıma sahip olabilirsiniz. Bu makalede, mikro hizmetler tasarlamaya yönelik etki alanı temelli bir yaklaşım gösterilmektedir.
Bu makalede çalışan bir örnek olarak insansız hava aracı teslim hizmeti gerçekleştirilir. Senaryo ve buna karşılık gelen 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 bağlantı ve yüksek işlevsel uyum olmalıdır. Bir hizmeti, diğer hizmetlerin aynı anda güncelleştirilmesine gerek kalmadan 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 uyumludur . Bir hizmet, etki alanı bilgilerini kapsüllemeli ve bu bilgiyi 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.
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, öncelikli olarak DDD ile ilgili 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 unutmamanız önemlidir. Hizmet sınırları taşla sabitlenmez. 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ı ile 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ını 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 etmelerine izin verme tuzakları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ı Ile Teslimat etki alanını gösteren kabaca bir taslak hazırladı.
- Gönderim , diyagramın merkezine yerleştirilir çünkü işletmenin temelidir. Bu işlevselliği etkinleştirmek için diyagramdaki diğer her şey vardır.
- İ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 gerektiğini tahmin etmek için tahmine dayalı analiz kullanılması yer alır.
- ETA analizi , teslim alma ve teslimat için zaman tahminleri sağlar.
- Bir paketin tamamen insansız hava aracıyla gönderilememesi durumunda üçüncü taraf taşıma, uygulamanın alternatif ulaşım yöntemlerini 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şleyebilecekleri bir diğer alandır.
- 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ı gerektiğinden, 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 güvenliğinin 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 ve 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ın 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ı gerekmez. 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 Gönderim, müşteriler hakkında bilgi almak için Kullanıcı Hesaplarına ve filodan insansız hava aracı zamanlamak için İnsansız Hava Aracı Yönetimi'ne bağlıdır.
Domain Driven Design 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ü korumak için ç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 çağırdığı iki desene karşılık gelir. Open Host Service'in fikri, alt sistemin diğer alt sistemlerin iletişim kurması için 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 Gönderim 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.
İlgili kaynaklar
Geri Bildirim
Çok yakında: 2024 boyunca, içerik için geri bildirim mekanizması olarak GitHub Sorunları’nı kullanımdan kaldıracak ve yeni bir geri bildirim sistemiyle değiştireceğiz. Daha fazla bilgi için bkz. https://aka.ms/ContentUserFeedback.
Gönderin ve geri bildirimi görüntüleyin