Farklı mikro servisler arasında paylaşılan alan modeli

İki farklı mikro hizmetin bir senaryosunu hayal edin. Biri hizmet içinde Kimlik Doğrulamayı idare etmek için diğeri Kullanıcı Yönetimi ile ilgilenir. Her ikisi de bir Kullanıcı kavramına sahiptir ve birbirlerini arayarak Kullanıcılar hakkında konuşacaklardır.

Bir "Kullanıcı" nın etki alanı modeli olsa nereye ait olurdu? Her ikisinin de bir Kullanıcının veritabanı seviyesinde ne olduğunun farklı bir temsili olur mu? API çağrılarında kullanılacak bir UserDTO'ya sahip olduğumuzda, her ikisinin de kendi API'leri için bir tane olur mu?

Bu tür mimari meseleler için genel kabul görmüş çözüm nedir?

Bir Microservices mimarisinde, her biri diğerlerinden kesinlikle bağımsızdır ve iç uygulamanın ayrıntılarını gizlemesi gerekir.

Modeli paylaşırsanız, mikro hizmetleri birleştiriyorsunuz ve her ekibin kendi sınırlarını olmadan mikro hizmetini geliştirebileceği ve diğerlerinin mikro hizmetlerini nasıl geliştireceğini bilme gereksiniminin en büyük avantajlarından birini kaybediyorsunuz. Her birinde farklı dilleri bile kullanabileceğinizi unutmayın, bu mikro hizmetleri bir araya getirmeye başladığınızda bu zor olacaktır.

Eğer onlar da birbirleriyle ilgiliyse belki de soru'nun dediği gibi.

İlgili sorular:

• Farklı bir mikro servisin "sahip olduğu" veritabanından veri okumak neden bu kadar kötü
• Bir mikro hizmet mimarisinde paylaşılan kavramları nasıl ele alırsınız?

İki hizmet yeterince iç içe geçmişse, DTO'ları ve diğer model nesnelerini paylaşmadan uygulamanın acı verici olacağı, bu iki hizmete sahip olmamanızın işareti olabilir.

Elbette, örnek iki hizmet olarak çok az anlam ifade ediyor; 'Kullanıcı yönetimi' için bir şartname hayal etmek zor, o kadar karmaşık ki bütün takımı o kadar meşgul edecek ki, doğrulama için vakti olmayacak.

Herhangi bir sebepten ötürü, OAuth 2.0'da olduğu gibi, temelde keyfi dizgelerin ne olduğunu kullanarak iletişim kuracaklardı .

Bunları iki ayrı Sınırlı Bağlam olarak düşünebilirsiniz (Domain-Driven Design parlance). Kimlik Doğrulama bağlamının "Kullanıcısı" nı, diğer bağlamın "Kullanıcısı" ile ilişkilendirmek için kullanılan bir kimlikten başka, aralarında veri paylaşmamalıdırlar. Her biri, bir "Kullanıcı" nın ne olduğunu ve yalnızca kendi sorumluluklarını yerine getirmek için gereken bilgilerin kendi alan modelini temsil edebilir.

Bir etki alanı modelinin gerçek bir dünya "şeyini" modellemeye çalışmadığını, bunun belirli bir bağlamda ne olduğunu (Kimlik / Yetkilendirme Yönetimi veya İnsan Kaynakları vb.) Hatırlayın.

Her ikisi de bir Kullanıcı kavramına sahiptir ve birbirlerini arayarak Kullanıcılar hakkında konuşacaklardır.

Ayrıca, ne soru söylediklerini kabul ediyorum. Bir servis başka bir servisin verisine ihtiyaç duyuyorsa, sınırları yanlış olur.

Güzel bir çözüm, pnschofield'ın geldiği şeydir - hizmetlerinizi Sınırlı bağlam olarak kabul etmek.

Konu hakkında konuşmak, kısaca söylemek gerekirse: paylaşılan alan modelleri, servis hizmetini dağıtır ve mikro servis sisteminizi dağıtılmış monolit haline getirir. Anlaşılan o ki, bir monolitten bile daha kötü.

Bu yüzden hala çözülemeyen genel bir soru var - hizmet veya bağlam sınırlarının nasıl tanımlanacağı, böylece yüksek tutarlılıkta ve gevşek kavrama iyiliği içinde gelişmeleri.

Bağlamlarımı iş yeteneği olarak değerlendirmek için bir çözüm buldum. Genel iş hedefine katkıda bulunan üst düzey bir işletme sorumluluğu, işletme işlevselliğidir. Bunları, kuruluşunuzun işletme değeri elde etmek için olsa yürümesi gereken adımlar olarak düşünebilirsiniz.

Servis sınırlarını belirlerken attığım tipik adım dizilim şöyle:

1. Daha üst düzey işletme yeteneklerini tanımlayın. Genellikle aynı etki alanındaki kuruluşlar arasında benzerdirler. Porter'ın değer zinciri modelini kontrol etmek gibi göründüğünü hissedebiliyorsun .
2. Her yetenek içinde daha derine inin ve alt yetenekleri tanımlayın.
3. Yetenekler arasındaki iletişimi not edin. Bir örgütün ne yaptığına bakın. Genellikle iletişim, çalışmalarının geri kalanı hakkında bilgi veren, yetenekler içinde yoğunlaşmıştır. Bu nedenle, teknik mimariyi uygularken, servisiniz de olaylar aracılığıyla iletişim kurmalıdır. Bunun çok sayıda olumlu sonucu var. Bu yaklaşımla hizmetleriniz özerk ve uyumludur. Senkronize iletişim ve dağıtılmış işlemlere ihtiyaçları yoktur.

Muhtemelen bu tekniğin bir örneği sizin için biraz ilgi çekici olacaktır. Bu yaklaşımı gerçekten karlı bulduğum için ne düşündüğünüzü söylememe çekinmeyin. Tabii ki senin için de işe yarayabilir.

Mikro hizmet "hiçbir şey paylaşma" değil, "mümkün olduğunca az paylaşma" ile ilgili değildir. Çoğu durumda "Kullanıcı" gerçekten yaygın bir varlıktır (yalnızca Kullanıcı bazı paylaşılan tanımlayıcı - kullanıcı kimliği / e-posta / telefon tarafından tanımlandığı için). Tanım tarafından paylaşılan bu tür varlıklar. Kullanıcı modeli kapsam dışı bir mikro servis değildir. Bu nedenle, Kullanıcının (sadece en yaygın alanları) yerleştirilmesi gereken bazı küresel şemalara sahip olmalısınız. Sıkı durumda sadece kimliktir.