Sınırlı bir bağlamın sınırlarını açıkça tanımlama

DDD'yi okuduktan ve araştırdıktan bir ay kadar sonra, kendi projemi başlatmaya karar verdim ve bu sınırlı bağlamlarla DDD oluşturdum>

• Müşteriler
• Ürün:% s
• Emirler
• fatura

Sınırlı her içerik, sunum katmanı, etki alanı katmanı, kalıcı katman olarak dinlenme API'sine sahiptir.

Şimdiye kadar iyi, kod düzgün çalışıyor, ancak yekpare bir dünyadan geliyor, hala aşağıdakileri anlamaya çalışıyorum:

• yeni bir müşteri oluşturmak istediğimde, yeni fatura düzenlediğimde, örneğin ülke listesine erişmek istediğim yeni sipariş oluşturduğumda. Ben:

a) her BC'de ülkelerin bir listesini oluşturmak

b) BC -> API Ülkeleri oluşturun ve mevcut ülkelerin bir listesini almak için kullanın

c) 3. taraf bir API kullanın ve her bir BC'de yolsuzlukla mücadele katmanı yoluyla veri çekin

• bir anti-yolsuzluk katmanı veya bir adaptör katmanı kullanarak 3. taraf API ile entegrasyon yaparken alan adı modelime hangi verilerin dahil edilmesi gerekir? Örneğin, bir zendesk API'sını Client BC ile entegre etmek istersem. Alan adımda bir ticketID'ye ihtiyacım var mı yoksa Zendesk'ten bir Müşteri BC'sine erişmek ve kullanmak istediğim tüm verileri çıkarmam gerekiyor mu?

MVC uygulamam aslında API'lardan veri alıyorsa (sınırlı bağlamlarımın sunum katmanları) Her BC'nin sınırlarını açıkça tanımlamakta zorlanıyorum. Düzgün tasarlanmış bir BC'nin ek API tüketmeye gerek kalmadan tek bir MVC denetleyicisine hizmet edeceği anlamına mı geliyor?

Farklı sınırlanmış bağlamlarınız bir ülkenin anlamını / amacını farklı bir şekilde anlıyorsa, ülkeyi her birinde uygun şekilde modellenmeniz gerekir. Ancak, sadece ISO kodlarının ve adlarının referans verilerinden bahsediyorsak, uygun olan her yerde saklamanın ve ilgili tüm taraflar için erişilebilir olmasını sağlamanın oldukça adil ve standart olduğuna inanıyorum. Örneğin: bir veritabanı, bir yapılandırma dosyası, bir web hizmeti, vb.

Ayrıca modelinize biraz bakmak istedim. Listelediğiniz parçalar, şirketin yapısına bağlı olarak bir "sınırlı bağlam" içinde "varlıklar" olabilir. BC'ler genellikle farklı alanlarda / departmanlarda / ekiplerde tanımlanır, çünkü bu genellikle “her yerde bulunan dil” ler arasındaki doğal sınırdır. Örneğin, Satış / Ürünler / Siparişler yerine BC'lerin Satış / Üretim / Depolama hatları boyunca olmasını beklerdim.

Bu BC'lerin içinde isimlere odaklanmıyorsunuz. Kullanım örneklerine odaklanır ve kullanım örneklerini yerine getirebilecek isimlerin modellerini yaratırsınız. "Toplam kök" üzerindeki yöntemler kullanım örneklerini yürütür ve ilgili modellerde uygun değişiklikleri yapar.

... tüm modeller yanlış, ama bazıları faydalı.

Ayrıca her BC'nin tamamen farklı bir sistem veya mimari kullanabileceğini unutmayın. Belirli bir BC "DDD yazılım bileşenlerini" kullanmayı hiç hak etmeyebilir ve çoğu muhtemelen kullanmaz. DDD, kuralcı yazılım bileşenleri ve yazılım tasarlama süreci hakkında daha azdır. Mesele, şirketin sınırlı bağlamlarını anlamaya, her bir bağlamın her yerde bulunan dillerini haritalamaya ve her yerde bulunan dillerini kullanarak bu bağlamın kodunu modellemeye odaklanmaktır. Bu şekilde, pay sahipleri ile etkileşimde bulunduğunuzda ve koda başvurduğunuzda, anladıkları iş terimleriyle konuştuğunuz gibi onlara seslenir. Ve aynı kelimenin farklı BC'lerde farklı anlamları olduğunu kabul etmek.

DDD tarafından getirilen, sona eren araçlardır (örn. Depo, özel katmanlama, vb.). Ancak bu kalıpların DDD dahilinde bile her durum için en iyi kalıp olduğu garanti edilmez. Tıpkı DDD'nin her proje için "" "cevabı olmadığı gibi. Yapmanız gereken en pratik şey analizinizin önerdiği şeyi yapmak.

Sorularınızdan, sınırlı bağlamı yanlış anladığınızı düşünüyorum. Mavi kitabın 14. Bölümünü tekrar okumak isteyebilirsiniz .

Genel olarak cevap vermeye çalışmak - kavramları iki farklı sınırlı bağlam arasında paylaşmak konusunda dikkatli olmalısınız. Sonuçta, sınırın var olma nedeninin bir kısmı her yerde bulunan dilin değişmesidir. Bir varlığın aynı verilerinin (ve aynı temsilin) ​​her iki bağlamda da kullanılabileceğini varsaymak naiftir - doğru olabilir, yanlış olabilir, ancak dışarıdaki, erişim olmadan bizim için iyi bir yol yoktur. etki alanı uzmanlarınıza, yargılamak için.

Örneğin, müşteri alanında "ülke" ikamet veya vatandaşlık ile ilgili olabilir. Faturalandırmada, döviz kurları ile ilgili olabilir. Bu alanlardan bazılarında tarifeler ve benzerleri hakkında endişelenmeniz gerekebilir.

Yükseltmeniz gereken ikinci soru, modellerinizden hangisinin "paylaşılan" veriler için kayıt defteri olmasıdır. "Ülke" durumunda, doğru cevap muhtemelen hiçbiri değildir! Jeopolitik topoloji modeliniz tarafından kontrol edilmez.

Bir ülke yabancı bir güç tarafından işgal edildiğinde etki alanı modellerinizde ne olması gerekiyordu?

Aklında tut; çoğumuz veri yapısı hakkında düşünmeye alışkınız; bir veri parçası ile diğeri arasındaki ilişki nedir. Raporları düşünürken ve ihtiyacınız olan tüm verilerin çözümünüz tarafından toplandığından emin olmaya çalışırken bu harika bir şey. Ancak etki alanı modelleri sadece yapı değil, değişimle de ilgilidir. Dikkatinizi bu kısma da koymanız ve verilerin değişiklikleri nasıl kısıtladığını (ve bu kısıtlamaların bir sınırlı bağlamdan diğerine nasıl değiştiğini) iyi anladığınızdan emin olmanız gerekir.

Bahsettiğiniz kavramlar (Müşteriler, Ürünler, Siparişler, Faturalandırma) genellikle tek bir Alan Modelinde ve dolayısıyla Sınırlı Bağlamda temsil edilir. Bu kavramları yanlış anlamanızı öneririm.

Bu konudaki görevim, bir iş yeteneği eşlemesi veya Değer zinciri analizi gibi diğer benzer teknikleri kullanarak sınırlı bağlam tanımlamaktır . Aşağıdaki adımlara gelir:

1. Sisteminizin üst düzey sorumluluklarını veya iş yeteneklerini tanımlayın. Bunu yapmanın en iyi yolu, işletmenizin bir iş değeri elde etmek için attığı adımları takip etmektir. Karşılaştığınız mantıksal sınırlar, iş hizmetleriniz veya isterseniz sınırlandırılmış bağlamlardır.
2. Her hizmetin derinliklerine inin.
3. İlk iki noktanın yanında hizmetleriniz arasındaki iletişimi belirleyin.

Bu nedenle ilk odak noktası işletmenizin nasıl işlediğidir.

Birkaç pratik tavsiye:

1. Bağlamlarınızdan / hizmetlerinizden vb. Birinin başka bir bağlamın verilerine ihtiyacı varsa, büyük olasılıkla sınırlarınız yanlıştır.
2. Bağlamsal iletişimin son derece arzu edilen yolu olay tabanlıdır. Bu ölçeklenebilirlik ve güvenilirliğin anahtarıdır. Eşzamanlı iletişime ihtiyacınız varsa, büyük olasılıkla sınırları yine yanlıştır. Bunun yanı sıra, senkron iletişim sisteminizi öldürecektir.
3. Alan adınız düşündüğünüzden daha tutarlı. Tıpkı herkes gibi. Her şeyi% 100 tutarlı hale getirmeye çalışmayın. Bunda pratik bir anlam yok.
4. Bağlamların düzenlenmesi gerekmez. Kendi kendine yetenler. İnsanlar gibi.

Bu yaklaşımla son derece özerk, bakımı kolay ve güvenilir hizmetler elde edersiniz. Bağlam sınırlarını tanımlamak için bir örnek kontrol etmek isteyebilirsiniz .