Her mikro hizmet için etki alanı modeli sınırlarını belirleme
İpucu
Bu içerik, .NET Docs'ta veya çevrimdışı olarak okunabilen ücretsiz indirilebilir bir PDF olarak sağlanan Kapsayıcılı .NET Uygulamaları için .NET Mikro Hizmet Mimarisi e-Kitabı'ndan bir alıntıdır.
Her mikro hizmet için model sınırlarını ve boyutunu belirlerken amaç mümkün olan en ayrıntılı ayrıma ulaşmak değildir, ancak mümkünse küçük mikro hizmetlere yönelmelisiniz. Bunun yerine, hedefiniz etki alanı bilginizin yönlendirdiği en anlamlı ayrıma ulaşmak olmalıdır. Vurgu boyuta değil, iş özelliklerine yöneliktir. Ayrıca, uygulamanın belirli bir alanı için çok sayıda bağımlılık temelinde net bir uyum gerekiyorsa, bu da tek bir mikro hizmet gereksinimini gösterir. Uyum, mikro hizmetleri ayırmayı veya gruplamanın bir yoludur. Sonuç olarak, etki alanı hakkında daha fazla bilgi edinirken mikro hizmetinizin boyutunu yinelemeli olarak uyarlamanız gerekir. Doğru boyutu bulmak tek seferlik bir işlem değildir.
Mikro hizmetlerin tanınmış bir destekleyicisi ve Mikro Hizmetler Oluşturma kitabının yazarı olan Sam Newman, mikro hizmetlerinizi daha önce tanıtıldığı gibi Sınırlanmış Bağlam (BC) desenine (etki alanı odaklı tasarımın bir parçası) göre tasarlamanız gerektiğini vurgular. İBH bazen çeşitli fiziksel hizmetlerden oluşsa da tam tersi de olmayabilir.
Belirli etki alanı varlıklarına sahip bir etki alanı modeli, somut bir BC veya mikro hizmet içinde uygulanır. BC, bir etki alanı modelinin uygulanabilirliğini sınırlandırır ve geliştirici ekip üyelerine nelerin uyumlu olması ve nelerin bağımsız olarak geliştirilebileceği konusunda net ve paylaşılan bir anlayış sağlar. Bunlar mikro hizmetler için aynı hedeflerdir.
Tasarım seçiminizi bilgilendiren bir diğer araç da Conway yasasıdır ve bu yasa, bir uygulamanın bunu üreten kuruluşun sosyal sınırlarını yansıtacağını belirtir. Ancak bazen tersi doğrudur - şirketin kuruluşu yazılım tarafından oluşturulur. Conway'in yasasını tersine çevirmeniz ve şirketin organize olmasını istediğiniz şekilde sınırları oluşturmanız ve iş süreci danışmanlığına eğilimli olmanız gerekebilir.
Sınırlanmış bağlamları tanımlamak için Bağlam Eşleme deseni adlı bir DDD deseni kullanabilirsiniz. Bağlam Eşleme ile uygulamadaki çeşitli bağlamları ve bunların sınırlarını belirlersiniz. Örneğin, her küçük alt sistem için farklı bir bağlam ve sınıra sahip olmak yaygındır. Bağlam Haritası, etki alanları arasında bu sınırları tanımlamanın ve açık hale getirmenin bir yoludur. BC otonomdur ve tek bir etki alanının ayrıntılarını (etki alanı varlıkları gibi ayrıntılar) içerir ve diğer BC'lerle tümleştirme sözleşmelerini tanımlar. Bu, mikro hizmetin tanımına benzer: otonomdur, belirli etki alanı özelliğini uygular ve arabirimler sağlaması gerekir. Bu nedenle Bağlam Eşleme ve Sınırlanmış Bağlam düzeni, mikro hizmetlerinizin etki alanı modeli sınırlarını belirlemek için iyi yaklaşımlardır.
Büyük bir uygulama tasarlarken, etki alanı modelinin nasıl parçalanabilir olduğunu göreceksiniz. Katalog etki alanındaki bir etki alanı uzmanı, katalog ve envanter etki alanlarındaki varlıkları örneğin sevkiyat etki alanı uzmanından farklı adlandıracaktır. Veya kullanıcı etki alanı varlığı, müşteriyle ilgili her ayrıntıyı depolamak isteyen bir CRM uzmanıyla ilgilenirken, müşteriyle ilgili kısmi verilere ihtiyaç duyan bir sipariş etki alanı uzmanından farklı olabilir. Büyük bir uygulamayla ilgili tüm etki alanlarında tüm etki alanı terimlerini kesinleştirmesi çok zordur. Ancak en önemli şey, koşulları birleştirmeye çalışmamanız gerektiğidir. Bunun yerine, her etki alanı tarafından sağlanan farklılıkları ve zenginliği kabul edin. Uygulamanın tamamı için birleşik bir veritabanına sahip olmaya çalışırsanız, birleşik bir kelime dağarcığı denemeleri garip olur ve birden çok etki alanı uzmanına uygun olmaz. Bu nedenle, BC'ler (mikro hizmetler olarak uygulanır), belirli etki alanı terimlerini nerede kullanabileceğinizi ve sistemi nerede bölmeniz ve farklı etki alanlarına sahip ek BC'ler oluşturmanız gerektiğini netleştirmenize yardımcı olur.
Etki alanı modelleri arasında çok az güçlü ilişki varsa ve genellikle tipik uygulama işlemlerini gerçekleştirirken birden çok etki alanı modelinden bilgileri birleştirmeniz gerekmiyorsa, her BC ve etki alanı modelinin doğru sınırlarına ve boyutlarına sahip olduğunuzu bilirsiniz.
Her mikro hizmet için bir etki alanı modelinin ne kadar büyük olması gerektiği sorusunun belki de en iyi yanıtı şudur: Mümkün olduğunca yalıtılmış, diğer bağlamlara (diğer mikro hizmetin modelleri) sürekli geçiş yapmanıza gerek kalmadan çalışmanızı sağlayan otonom bir İBH'ye sahip olmalıdır. Şekil 4-10'da, uygulamanızda tanımlanan her etki alanının belirli gereksinimlerine bağlı olarak, birden çok mikro hizmetin (birden çok BC) kendi modeline sahip olduğunu ve varlıklarının nasıl tanımlanabileceğini görebilirsiniz.
Şekil 4-10. Varlıkları ve mikro hizmet modeli sınırlarını tanımlama
Şekil 4-10'da çevrimiçi konferans yönetim sistemiyle ilgili örnek senaryo gösterilmektedir. Sınırlanmış bağlama bağlı olarak aynı varlık "Kullanıcılar", "Alıcılar", "Payers" ve "Müşteriler" olarak görünür. Etki alanı uzmanlarının sizin için tanımladığı etki alanlarına göre mikro hizmet olarak uygulanabilecek çeşitli BC'ler belirlediniz. Gördüğünüz gibi, Ödeme mikro hizmetindeki Ödemeler gibi yalnızca tek bir mikro hizmet modelinde bulunan varlıklar vardır. Bunları uygulamak kolay olacaktır.
Ancak, farklı bir şekle sahip olan ancak aynı kimliği birden çok mikro hizmetten birden çok etki alanı modeli arasında paylaşan varlıklarınız da olabilir. Örneğin, Kullanıcı varlığı Konferans Yönetimi mikro hizmeti içinde tanımlanır. Aynı kimlikle aynı kullanıcı, Sipariş mikro hizmetinde Alıcılar adlı kullanıcı, Ödeme mikro hizmetinde Payer adlı kullanıcı ve hatta Customer Service mikro hizmetinde Müşteri adlı kullanıcıdır. Bunun nedeni, her etki alanı uzmanının kullandığı yaygın dile bağlı olarak kullanıcının farklı özniteliklere sahip olsa bile farklı bir perspektife sahip olmasıdır. Konferans Yönetimi adlı mikro hizmet modelindeki kullanıcı varlığı, kişisel veri özniteliklerinin çoğuna sahip olabilir. Ancak, mikro hizmet Ödemesinde Payer şeklinde veya mikro hizmet müşteri hizmetlerindeki Müşteri şeklindeki aynı kullanıcının aynı öznitelik listesine ihtiyacı olmayabilir.
Benzer bir yaklaşım Şekil 4-11'de gösterilmiştir.
Şekil 4-11. Geleneksel veri modellerini birden çok etki alanı modeline ayırma
Sınırlanmış bağlamlar arasında geleneksel bir veri modelini ayrıştırırken, her sınırlanmış bağlamda farklı özniteliklere sahip aynı kimliği (alıcı aynı zamanda bir kullanıcıdır) paylaşan farklı varlıklara sahip olabilirsiniz. Kullanıcının Konferans Yönetimi mikro hizmet modelinde Kullanıcı varlığı olarak nasıl mevcut olduğunu ve fiyatlandırma mikro hizmetindeki Alıcı varlığı biçiminde, aslında alıcı olduğunda kullanıcıyla ilgili alternatif öznitelikler veya ayrıntılarla nasıl mevcut olduğunu görebilirsiniz. Her mikro hizmet veya BC, çözülecek soruna veya bağlama bağlı olarak bir Kullanıcı varlığıyla ilgili tüm verilere ihtiyaç duymayabilir. Örneğin Fiyatlandırma mikro hizmet modelinde, kullanıcının adresine veya adına ihtiyacınız yoktur; yalnızca kimlik (kimlik olarak) ve Durum değerlerine ihtiyacınız yoktur. Bu, alıcı başına koltukları fiyatlandırma sırasında indirimleri etkiler.
Seat varlığı, her etki alanı modelinde aynı ada ama farklı özniteliklere sahiptir. Ancak Seat, Kullanıcı ve Alıcı ile olduğu gibi aynı kimliğe göre kimlik paylaşır.
Temel olarak, birden çok hizmette (etki alanında) bulunan ve tümü bu kullanıcının kimliğini paylaşan paylaşılan bir kullanıcı kavramı vardır. Ancak her etki alanı modelinde kullanıcı varlığı hakkında ek veya farklı ayrıntılar olabilir. Bu nedenle, bir kullanıcı varlığını bir etki alanından (mikro hizmet) diğerine eşlemenin bir yolu olmalıdır.
Aynı kullanıcı varlığını etki alanları arasında aynı sayıda öznitelikle paylaşmamanın çeşitli avantajları vardır. Bunun bir avantajı, mikro hizmet modellerinin ihtiyaç duymadığı herhangi bir veriye sahip olmaması için yinelemeyi azaltmaktır. Başka bir avantaj, varlık başına belirli bir veri türüne sahip olan birincil mikro hizmete sahip olmaktır, böylece bu tür veriler için güncelleştirmeler ve sorgular yalnızca bu mikro hizmet tarafından yönlendirilir.
