Aracılığıyla paylaş

Mikro hizmet etki alanı modeli tasarlama

  • Makale

İ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.

PDF'i indirin

.NET Microservices Architecture for Containerized .NET Applications eBook cover thumbnail.

Her iş mikro hizmeti veya Sınırlanmış Bağlam için bir zengin etki alanı modeli tanımlayın.

Amacınız, her iş mikro hizmeti veya Sınırlanmış Bağlam (BC) için tek bir uyumlu etki alanı modeli oluşturmaktır. Bununla birlikte, bc veya iş mikro hizmetinin bazen tek bir etki alanı modelini paylaşan birkaç fiziksel hizmetlerden oluşabileceğini unutmayın. Etki alanı modeli, temsil ettiği tek Sınırlanmış Bağlamın veya iş mikro hizmetinin kurallarını, davranışını, iş dilini ve kısıtlamalarını yakalamalıdır.

Etki Alanı Varlığı düzeni

Varlıklar etki alanı nesnelerini temsil eder ve öncelikle kimlikleri, sürekliliği ve zaman içindeki kalıcılığı ile tanımlanır ve yalnızca bunları oluşturan öznitelikler tarafından tanımlanmaz. Eric Evans'ın dediği gibi, "öncelikli olarak kimliği tarafından tanımlanan bir nesne varlık olarak adlandırılır." Varlıklar, bir modelin temeli olduğundan etki alanı modelinde çok önemlidir. Bu nedenle, bunları dikkatlice tanımlamanız ve tasarlamanız gerekir.

Bir varlığın kimliği birden çok mikro hizmet veya Sınırlanmış Bağlamlar arasında geçiş yapabilir.

Aynı kimlik ( Id aynı değer, aynı etki alanı varlığı olmasa da) birden çok Sınırlanmış Bağlam veya mikro hizmette modellenebilir. Ancak bu, aynı özniteliklere ve mantığa sahip aynı varlığın birden çok Sınırlanmış Bağlamda uygulanacağı anlamına gelmez. Bunun yerine, her Sınırlanmış Bağlamdaki varlıklar özniteliklerini ve davranışlarını bu Sınırlanmış Bağlamın etki alanında gerekli olanlarla sınırlar.

Örneğin, alıcı varlığı, kimlik dahil olmak üzere profil veya kimlik mikro hizmetindeki kullanıcı varlığında tanımlanan bir kişinin özniteliklerinin çoğuna sahip olabilir. Ancak sipariş mikro hizmetindeki alıcı varlığının öznitelikleri daha az olabilir çünkü sipariş işlemiyle ilgili yalnızca belirli alıcı verileri vardır. Her mikro hizmetin veya Sınırlanmış Bağlamın bağlamı, etki alanı modelini etkiler.

Etki alanı varlıkları, veri özniteliklerini uygulamaya ek olarak davranış uygulamalıdır.

DDD'deki bir etki alanı varlığı, varlık verileriyle (bellekte erişilen nesne) ilgili etki alanı mantığını veya davranışını uygulamalıdır. Örneğin, bir sipariş varlığı sınıfının parçası olarak, sipariş öğesi ekleme, veri doğrulama ve toplam hesaplama gibi görevler için yöntemler olarak iş mantığının ve işlemlerin uygulanması gerekir. Varlığın yöntemleri, bu kuralların uygulama katmanına yayılması yerine varlığın sabitlerini ve kurallarını üstlenir.

Şekil 7-8'de yalnızca veri özniteliklerini değil, ilgili etki alanı mantığına sahip işlemleri veya yöntemleri uygulayan bir etki alanı varlığı gösterilmektedir.

Diagram showing a Domain Entity's pattern.

Şekil 7-8. Veri artı davranışı uygulayan bir etki alanı varlığı tasarımı örneği

Etki alanı modeli varlığı yöntemler aracılığıyla davranışlar uygular, yani "anemik" bir model değildir. Elbette, bazen varlık sınıfının bir parçası olarak herhangi bir mantık uygulamayan varlıklara sahip olabilirsiniz. Mantığın çoğu toplama kökünde tanımlandığından alt varlığın herhangi bir özel mantığı yoksa, bu durum bir toplama içindeki alt varlıklarda oluşabilir. Etki alanı varlıkları yerine hizmet sınıflarında mantık uygulanmış karmaşık bir mikro hizmetiniz varsa, aşağıdaki bölümde açıklanan anemik etki alanı modeline düşebilirsiniz.

Zengin etki alanı modeli ile anemik etki alanı modeli karşılaştırması

Martin Fowler, AnemicDomainModel sonrasında anemik etki alanı modelini şu şekilde açıklar:

Anemik Etki Alanı Modelinin temel belirtisi, ilk başta gerçek şeye benzemiş gibi görünmesidir. Etki alanı alanındaki isimlerden sonra adlandırılmış birçok nesne vardır ve bu nesneler, gerçek etki alanı modellerinin sahip olduğu zengin ilişkiler ve yapıyla bağlantılıdır. Yakalama, davranışa baktığınızda gelir ve bu nesneler üzerinde neredeyse hiç davranış olmadığını fark edersiniz ve bu da onları alıcı ve ayarlayıcı torbalarından biraz daha fazla hale getirir.

Elbette, anemik bir etki alanı modeli kullandığınızda, bu veri modelleri tüm etki alanını veya iş mantığını yakalayan bir dizi hizmet nesnesinden (geleneksel olarak iş katmanı olarak adlandırılır) kullanılır. İş katmanı, veri modelinin en üstünde yer alır ve veri modelini aynı veri olarak kullanır.

Anemik etki alanı modeli yalnızca yordam stili bir tasarımdır. Anemik varlık nesneleri, davranış (yöntemler) eksikliği nedeniyle gerçek nesneler değildir. Yalnızca veri özelliklerini barındırırlar ve bu nedenle nesne odaklı tasarım değildir. Tüm davranışı hizmet nesnelerine (iş katmanı) yerleştirerek temelde spagetti kodu veya işlem betikleriyle sonuçlanırsınız ve bu nedenle bir etki alanı modelinin sağladığı avantajları kaybedersiniz.

Ne olursa olsun, mikro hizmetiniz veya Sınırlanmış Bağlamınız çok basitse (CRUD hizmeti), yalnızca veri özelliklerine sahip varlık nesneleri biçimindeki anemik etki alanı modeli yeterince iyi olabilir ve daha karmaşık DDD desenleri uygulamaya değmeyebilir. Bu durumda, yalnızca CRUD amacıyla yalnızca veri içeren bir varlığı kasıtlı olarak oluşturduğunuz için bu yalnızca bir kalıcılık modeli olacaktır.

Bu nedenle mikro hizmet mimarileri, Her Sınırlanmış Bağlama bağlı olarak çok mimarili bir yaklaşım için mükemmeldir. Örneğin, eShopOnContainers'da sipariş mikro hizmeti DDD desenleri uygular, ancak basit bir CRUD hizmeti olan katalog mikro hizmeti uygulanmaz.

Bazı kişiler anemik etki alanı modelinin bir anti-desen olduğunu söylüyor. Bu gerçekten ne uyguladığınıza bağlıdır. Oluşturduğunuz mikro hizmet yeterince basitse (örneğin, bir CRUD hizmeti), anemik etki alanı modelini takip eden bu bir anti-desen değildir. Ancak, sürekli değişen çok sayıda iş kuralına sahip bir mikro hizmetin etki alanının karmaşıklığını ele almanız gerekiyorsa, anemik etki alanı modeli bu mikro hizmet veya Sınırlanmış Bağlam için bir anti-desen olabilir. Bu durumda, veri artı davranış içeren varlıklara sahip zengin bir model olarak tasarlamanın yanı sıra ek DDD desenleri (toplamalar, değer nesneleri vb.) uygulamak, böyle bir mikro hizmetin uzun vadeli başarısı için büyük avantajlara sahip olabilir.

Ek kaynaklar

Değer Nesnesi deseni

Eric Evans'ın da belirttiği gibi, "Birçok nesne kavramsal kimliğe sahip değildir. Bu nesneler bir şeyin belirli özelliklerini açıklar."

Varlık bir kimlik gerektirir, ancak sistemde Değer Nesnesi deseni gibi olmayan birçok nesne vardır. Değer nesnesi, bir etki alanı yönünü açıklayan kavramsal kimliği olmayan bir nesnedir. Bunlar, yalnızca geçici olarak sizi ilgilendiren tasarım öğelerini temsil etmek için örneklediğiniz nesnelerdir. Kim olduklarına değil, ne olduklarına önem veriyorsunuz. Örnekler arasında sayılar ve dizeler yer alır, ancak öznitelik grupları gibi daha üst düzey kavramlar da olabilir.

İkinci durumda Sınırlanmış Bağlamın farklı bir anlamı olabileceğinden, mikro hizmetteki bir varlık başka bir mikro hizmetteki varlık olmayabilir. Örneğin, bir e-ticaret uygulamasındaki bir adres, bir kişi veya şirket için yalnızca müşteri profilinin özniteliklerinden oluşan bir grubu temsil ettiğinden hiç bir kimliğe sahip olmayabilir. Bu durumda, adres bir değer nesnesi olarak sınıflandırılmalıdır. Ancak, bir elektrik elektrik şebekesi şirketi için bir uygulamada, müşteri adresi iş alanı için önemli olabilir. Bu nedenle, fatura sisteminin adrese doğrudan bağlanabilmesi için adresin bir kimliği olmalıdır. Bu durumda, bir adres bir etki alanı varlığı olarak sınıflandırılmalıdır.

Ad ve soyadı olan bir kişi genellikle bir varlıktır, çünkü ad ve soyadı başka bir değer kümesiyle çakışsa bile (örneğin, bu adlar farklı bir kişiye başvuruyorsa) bir kişi kimliğe sahiptir.

Değer nesnelerinin varlık çerçevesi (EF) gibi ilişkisel veritabanlarında ve ORM'lerde yönetilmesi zorken, belge odaklı veritabanlarında bunları uygulamak ve kullanmak daha kolaydır.

EF Core 2.0 ve sonraki sürümleri, daha sonra ayrıntılı olarak göreceğimiz gibi değer nesnelerinin işlenmesini kolaylaştıran Sahip Olunan Varlıklar özelliğini içerir.

Ek kaynaklar

Toplama düzeni

Etki alanı modeli, sipariş karşılama veya envanter gibi önemli bir işlevsellik alanını denetleyebilen farklı veri varlıklarından ve işlemlerinden oluşan kümeler içerir. Daha ayrıntılı bir DDD birimi, bir kümeyi veya bir grup varlığı ve birlikte çalışma birimi olarak kabul edilebilecek davranışları açıklayan toplama birimidir.

Genellikle ihtiyacınız olan işlemlere göre bir toplama tanımlarsınız. Klasik örnek, sipariş öğelerinin listesini de içeren bir sipariştir. Sipariş öğesi genellikle bir varlık olur. Ancak, genellikle toplama kökü olarak adlandırılan kök varlığı olarak sipariş varlığını da içeren sipariş toplama içindeki bir alt varlık olacaktır.

Toplamaları belirlemek zor olabilir. Toplama, birlikte tutarlı olması gereken bir nesne grubudur, ancak yalnızca bir grup nesne seçip bunları bir toplama olarak etiketleyemezsiniz. Bir etki alanı kavramıyla başlamanız ve bu kavramla ilgili en yaygın işlemlerde kullanılan varlıkları düşünmeniz gerekir. İşlemsel olarak tutarlı olması gereken varlıklar, toplamayı oluşturan varlıklardır. Toplamaları tanımlamanın en iyi yolu muhtemelen işlem işlemlerini düşünmektir.

Toplama Kökü veya Kök Varlık deseni

Toplama en az bir varlıktır: kök varlık veya birincil varlık olarak da adlandırılan toplama kökü. Ayrıca, gerekli davranışı ve işlemleri uygulamak için tüm varlıkların ve nesnelerin birlikte çalıştığı birden çok alt varlık ve değer nesnesine sahip olabilir.

Toplama kökünün amacı, toplamanın tutarlılığını sağlamaktır; toplama kök sınıfındaki yöntemler veya işlemler aracılığıyla toplama güncelleştirmeleri için tek giriş noktası olmalıdır. Yalnızca toplama kökü aracılığıyla toplama içindeki varlıklarda değişiklik yapmanız gerekir. Toplama işleminizde uymanız gerekebilecek tüm sabit ve tutarlılık kurallarını göz önünde bulundurarak, toplamanın tutarlılık koruyucusudur. Bir alt varlığı veya değer nesnesini bağımsız olarak değiştirirseniz, toplama kökü toplamanın geçerli bir durumda olduğundan emin olamaz. Bacağı gevşek bir masa gibi olurdu. Tutarlılığı korumak, toplama kökünün ana amacıdır.

Şekil 7-9'da, tek bir varlık (toplam kök Alıcı) içeren alıcı toplaması gibi örnek toplamaları görebilirsiniz. Sipariş toplaması birden çok varlık ve bir değer nesnesi içerir.

Diagram comparing a buyer aggregate and an order aggregate.

Şekil 7-9. Birden çok veya tek varlıklı toplama örneği

DDD etki alanı modeli toplamalardan oluşur, bir toplama yalnızca bir veya daha fazla varlığa sahip olabilir ve değer nesnelerini de içerebilir. Alıcı toplamasının, eShopOnContainers başvuru uygulamasındaki mikro hizmeti sıralamada olduğu gibi etki alanınıza bağlı olarak ek alt varlıklara sahip olabileceğini unutmayın. Şekil 7-9'da yalnızca alıcının tek bir varlığa sahip olduğu bir servis talebi gösterilmektedir. Yalnızca toplama kökü içeren bir toplama örneğidir.

Toplamaların ayrımını korumak ve aralarında net sınırlar tutmak için, eShopOnContainers'da mikro hizmet etki alanı modelini sıralama bölümünde uygulandığı gibi, DDD etki alanı modelinde toplamalar arasında doğrudan gezintiye izin vermemek ve yalnızca yabancı anahtar (FK) alanına sahip olmak iyi bir uygulamadır. Sipariş varlığı, aşağıdaki kodda gösterildiği gibi yalnızca alıcı için bir yabancı anahtar alanına sahiptir, ancak EF Core gezinti özelliğine sahip değildir:

public class Order : Entity, IAggregateRoot
{
    private DateTime _orderDate;
    public Address Address { get; private set; }
    private int? _buyerId; // FK pointing to a different aggregate root
    public OrderStatus OrderStatus { get; private set; }
    private readonly List<OrderItem> _orderItems;
    public IReadOnlyCollection<OrderItem> OrderItems => _orderItems;
    // ... Additional code
}

Toplamaları tanımlamak ve bunlarla çalışmak için araştırma ve deneyim gerekir. Daha fazla bilgi için aşağıdaki Ek kaynaklar listesine bakın.

Ek kaynaklar

Geriİleri