DDD Sınırlı Bağlamlar ve Etki Alanları?

Ben 10 'lerin veritabanı tabloları (Toplamlar, Varlıklar / Değer Nesneleri) ile nispeten karmaşık bir uygulama üzerinde çalışıyorum ve DDD uygulamak. Bu noktada temelde DDD-Lite gibi görünüyor ki Uygulama / Etki Alanı Hizmetleri, Etki Alanı Modeli (Varlıklar, Değer Nesneleri) ve Depolar var.

DDD'yi uygulayan bir kitap aldım ve bahsettiği ilk şey DDD-Lite ve Sınırlı Bağlamlar ve Alan Olayları DDD'ye başlarken olağan ilk hatalar olarak eksik.

Şu anda Etki Alanı Modelini Toplu ilişkilere göre düzenlemeyi ve göstermek için ad alanlarını kullanmayı denedim.

Etki Alanı Modeli projesinin ayrı Sınırlı bağlamlara (henüz) ayrılmasıyla ilgili faydaları / düşüşleri göremiyorum. Belki daha sonra belirginleşecektir, ancak Sınırlı Bağlamlar (ve muhtemelen alt etki alanları vb.

Birkaç farklı departmanı olan bir şirketi düşünün:

• Yazılım geliştirme
• İK
• Muhasebe

Tüm bu iş alanlarını ifade edebilecek bir kullanıcı modeli bulabilir misiniz? Kullanıcı varlığının her birinde nasıl görünebileceğini düşünün. Belki de üç farklı varlığa ayrılmıştır:

• Geliştirici
• işçi
• Alacaklı

Bir kullanıcıyı her bağlamda somutlaştırma çabası oldukça farklıdır. Belki de böyle bir şey:

• yeni Çalışan (ssn, isim, joindate, doğum tarihi, cinsiyet)
• yeni Geliştirici (Çalışan, iş istasyonu, kimlik bilgileri)
• yeni Alacaklı (Çalışan, rol)

mazeret, referans için uygun bir alan adı modeli olmadan doğru bir şekilde göstermek zor

Saf bir uygulama kullandıysanız ve tek bir kullanıcı varlığı kullandıysanız, alıcılar ve ayarlayıcılarla dolu anemik bir veri modeli olur, çünkü kullanıcıyı her yerde tam olarak temsil edemezdiniz.

İşletmede net sınırlar var, bu yüzden onları bu şekilde modellemek yararlıdır. Bir bordro sistemindeki bir kullanıcıya karşı bir oyun oynayan bir kullanıcıya karşı giriş yapan bir kullanıcı, aynı büyük sistemin parçası olsalar bile hepsi çok farklıdır.

Başka bir şekilde düşünmek - artık çok hafif ve sisteminizin geri kalanından bağımsız olmak için geliştirici yönetim kodunuzu oluşturabilirsiniz. Endişelenmek için daha az bagajla daha doğru tipler kullanabilir. Nihayetinde kendi uygulamasına çıkarılabilecek daha küçük alt sistemler oluşturma adımıdır.

Sana başka bir örnek verebilirim. Bazı e-ticaret sisteminiz olduğunu düşünün. Orada ürünleriniz olur, ancak ürünler en az iki farklı alanın parçası olur:

• Ürün açıklamanızı ve tüm özelliklerinizi sakladığınız ürün kataloğu
• Ürün stok seviyesine sahip olduğunuz envanter

Her iki alan için de sınırlı bir bağlamınız varsa, çözümünüz hızla büyük bir çamur topu haline gelebilir, çünkü çapraz referans vermeye başlayacaksınız. Sonunda artık iki alanınız olmayacak. Ürün envanteriniz ürün kataloğu referansları ile şımartılacak veya tam tersi. Bunun sonucu olarak, bunun gerekli olmadığını tam olarak anlasanız bile, bir alanı başka bir alana dokunmadan değiştiremezsiniz. Modelleriniz birbirine bağımlı, sıkıca bağlı ve kötü bir şekilde bağımlı - uygulamaya bağlı.

Bununla birlikte, iki sınırlı bağlamınız varsa, bir etki alanında yaptığınız tüm değişiklikler, iletişim kanallarınızı temiz tutar tutmaz diğerini etkilemez. Bu, veri çoğaltmanızın olması gerektiği anlamına gelecektir, ancak bu, yakın birleşik bileşen tabanlı uygulama için en düşük maliyettir. Alan adlarınız, alan adı etkinliklerini kullanarak birbirleriyle konuşabilir. Başlangıçta SOA tabanlı bir uygulamaya sahip olmayı planlamasanız bile, nispeten düşük çaba ile ihtiyacınız olduğunda bu seviyeye kadar ölçeklendirebileceksiniz, çünkü sadece alan etkinlikleriniz için aktarımı değiştirdiğiniz ve arkasındaki fikri olduğu gibi bırakacaksınız.

Güncelleme: SkillsMatter'da Eric Evans'dan iyi bir beceri var. Birkaç kör adam bir fili kendi perspektifinden tarif ettiğinde eski hikayenin bir benzetmesini verir. Her insan filin sadece bir kısmına dokunabildiğinden, onu bir "ağaç", "duvar", "yılan", "ip" olarak tanımlarlar. Ve bu insanların her biri kendi bağlamları içinde. Sınırlı bağlam her yerde bulunan dilin yaşadığı yerdir. Bağlamın dışında, bu terimler tamamen farklı bir anlama sahip olabilir, ancak bağlam içinde, dil birden fazla alanda aynıdır. Greg Young bölüm 11'deki mavi kitabı okumaya başlamanızı şiddetle tavsiye ediyor, çünkü burada en önemli, temel kavramlar açıklanıyor. Kitabın başındaki taktik kalıplara odaklanma, bu "DDD-light" yaklaşımını çok yaygın kılıyor,