Not
Bu sayfaya erişim yetkilendirme gerektiriyor. Oturum açmayı veya dizinleri değiştirmeyi deneyebilirsiniz.
Bu sayfaya erişim yetkilendirme gerektiriyor. Dizinleri değiştirmeyi deneyebilirsiniz.
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ı üreten mekanik bir işlem yoktur. İş etki alanınız, gereksinimleriniz, mimari özellikleriniz ( işlev dışı 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 özellikleri sergileyen gelişigüzel 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 daha fazla uygulama geliştirme gerektiren mevcut sınırların yeniden tanımlarıyla sonuçlanır.
Bu makalede sürekli bir örnek olarak insansız hava aracı ile teslimat hizmeti kullanılır. Senaryo ve buna karşılık gelen başvuru uygulaması hakkında daha fazla bilgi için bkz. Mikro hizmet mimarisi tasarlama.
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ğlılık 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 mikroservis için mimari özellikler, tüm sistem yerine, alanın gereksinimleriyle uyumlu hale getirilerek tanımlanmalıdır. Ö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 bağlanmış 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 çıktısı, daha resmi bir etki alanı model setine dönüştürülebilecek, resmi olmayan bir etki alanı tanımıdır.
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 senaryo oldukça karmaşık bir etki alanı içerir. İşle ilgili en önemli sorunlardan bazıları insansız hava araçlarını zamanlamak, paketleri izlemek, kullanıcı hesaplarını yönetmek ve geçmiş verileri depolamak ve analiz etmektir. Fabrikam, pazara hızla çıkmayı ve hızlı yinelemeler yaparak, yeni işlevler ve yetenekler eklemeyi de hedeflemektedir. Uygulamanın bulut ölçeğinde çalışması ve yüksek hizmet düzeyi hedefini karşılaması gerekir. Ayrıca Fabrikam, sistemin farklı bölümlerinin veri depolama ve sorgulama için farklı gereksinimlere sahip olmasını bekler. Bu önemli noktalar Fabrikam'ın İnsansız Hava Aracı Ile Teslimat uygulaması için bir mikro hizmet mimarisi benimsemesine yol açar.
Etki alanını analiz etme
DDD yaklaşımı, 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 sistem hakkında üst düzey bir anlayışa sahip olmanız gerekir. 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 damıtır ve düzenler ve geliştiriciler ve etki alanı uzmanları için ortak bir dil sağlar.
Tüm iş işlevlerini ve bağlantılarını eşleyerek başlayın. Bu çaba, etki alanı uzmanlarını, yazılım mimarlarını ve diğer paydaşları içeren bir işbirliği olabilir. Belirli bir biçim kullanmanıza gerek yoktur. Bir diyagram çizin veya beyaz tahta üzerinde çizim yapın.
Diyagramı doldururken, ayrık alt etki alanlarını tanımlamaya başlayabilirsiniz. Hangi işlevler yakından ilişkili? İşletmenin temel işlevleri hangileridir ve hangi işlevler yardımcı hizmetler sağlar? Bağımlılık grafiği nedir? Bu ilk aşama sırasında teknolojilerle veya uygulama ayrıntılarıyla ilgilenmezsiniz. Bununla birlikte, uygulamanın müşteri ilişkileri yönetimi, ödeme işleme veya faturalama sistemleri gibi dış sistemlerle tümleştirilmesi gereken yeri not edin.
Ö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 uygulamaya sızma riski vardır. Bu tür bir sızıntı mimari tasarımı tehlikeye atabilir. Bu, özellikle modern en iyi yöntemleri izlemeyen eski sistemlerde yaygındır ve birleştirilmiş veri şemaları veya eski API'ler kullanabilir. Bu gibi durumlarda, dış sistem ve uygulama arasında iyi tanımlanmış bir sınır oluşturmak önemlidir. Bu sınırı uygulamak için Strangler Fig desenini veya Bozulma önleyici katman desenini kullanmayı düşünün.
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 zamanını ayarlamak gerektiğinde, bu şeyler umurumuzda olmaz. 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, belirli bir etki alanı modelinin uygulandığı etki alanı içindeki sınırı tanımlar. Önceki diyagrama bakarak, farklı işlevlerin aynı etki alanı modelini paylaşıp paylaşmadığına göre işlevleri gruplandırabilirsiniz.
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ırlı bağlamına odaklanacağı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.