Aracılığıyla paylaş

Mikro hizmet etki alanı modeli tasarlama

Tavsiye

Bu içerik, .NET Docs veya çevrimdışı olarak okunabilen ücretsiz indirilebilir bir PDF olarak sağlanan Kapsayıcılı .NET Uygulamaları için .NET Mikro Hizmet Mimarisi adlı e-Kitap'tan bir alıntıdır.

PDF'i indirin

.NET Mikro Hizmetler Mimarisi Kapsayıcılı .NET Uygulamaları için eKitabın kapak küçük resmi .

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.

Domain Varlığı kalıbı

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 (aynı c0 /> değeri, ancak belki aynı etki alanı varlığı değil) birden çok Sınırlanmış Bağlam veya mikro hizmetlerde 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ı birimi, kimliği de içeren profil veya kimlik mikroservisindeki kullanıcı biriminde tanımlanan bir kişinin özelliklerinin ç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, varlığın değişmezlerini ve kurallarını yöneterek bu kuralların uygulama katmanına yayılmasını önler.

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

Etki Alanı Varlığının düzenini gösteren diyagram.

Ş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 gönderisinde anemik bir 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. Sorun, davranışa baktığınızda ortaya çıkar, ve bu nesneler üzerinde neredeyse hiç davranış olmadığını fark ettiğinizde, onları basitçe alıcı ve ayarlayıcı yığını haline 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 prosedürel stil 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 mikroservis yeterince basitse (örneğin, bir CRUD servisi), anemik etki alanı modelini takip etmek 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

Kümelenme deseni

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 arada tutarlı bir birim olarak ele alınabilecek varlıklar ve davranışlar grubunu veya kümesini tanımlayan agrega 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. Fakat, sipariş varlığı içerisinde kök varlık olarak yer alacak olan ve genellikle toplama kökü olarak adlandırılan sipariş topluluğu içinde bir alt birim 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 Nesne deseni

Bir bütün, en az bir varlıktan oluşur: bütün kökü, aynı zamanda kök varlık veya birincil varlık olarak da adlandırılan bu varlı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. Veri kümeniz içinde uymanız gerekebilecek tüm sabit ve tutarlılık kurallarını göz önünde bulundurarak, veri kümesinin tutarlılığı sağlayan unsurdur. Bir varlık veya değer nesnesini bağımsız olarak değiştirirseniz, küme kökü kümenin geçerli bir durumda olduğunu garanti edemez. 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 (topluluk kökü Alıcı) içeren alıcı topluluğu gibi örnek toplulukları görebilirsiniz. Sipariş toplamı birden çok varlık ve bir değer nesnesi içerir.

Alıcı toplaması ile sipariş toplamlarını karşılaştıran diyagram.

Ş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ı agregasının, eShopOnContainers referans uygulamasındaki sipariş mikro hizmetinde olduğu gibi, etki alanınıza bağlı olarak ek alt birimlere sahip olabileceğini unutmayın. Şekil 7-9, yalnızca bir kök varlık içeren bir toplamanın örneği olarak alıcının tek bir varlığa sahip olduğu bir durumu göstermektedir.

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

ÖncekiSonraki