DTO nesnelerini mikro hizmetler arasında paylaşma

TL; DR - Bir POJO kütüphanesini hizmetler arasında paylaşmak uygun mudur?

Genel olarak, hizmetler arasındaki paylaşımın mümkünse kesinlikle sınırlı kalmasını isteriz. Veri paylaşan hizmetin, istemcilerin kullanması için bir istemci kitaplığı sağlayıp sağlamayacağı konusunda bazı tartışmalar olmuştur. İstemci-lib, hizmetin bir istemcisinin kullanması için genellikle isteğe bağlıdır ve API'yı tüketebilir, ancak istemci-lib'in kullanılmasını veya alternatif bir dil kullanıp kütüphanenin genel özelliklerini kullanmasını ister.

Benim durumumda - bir veri nesnesi oluşturan bir hizmet olduğunu düşünüyorum. Bu nesnenin bir PET olduğunu varsayalım. Veritabanı varlığı DEĞİLDİR, ama kesinlikle temeldeki verileri dolaylı olarak temsil eden POJO'dur. Bu POJO, API'nın tanımladığı şeydir. Varsayın: Evcil Hayvan - Yaş, Ağırlık, İsim, Sahip, Adres, Türler, vb.

Hizmet 1 - PetKeeper: Hangi nedenle olursa olsun bir evcil hayvan üretecek ve tüm verileri saklayacak ve evcil hayvanı elde etmek veya Evcil Hayvan üzerinde değişiklik yapmak için bu hizmete başvurmalıdır, ad değişikliklerinin veya adres değişikliğinin bir Bu hizmet için API çağrısı.

Servis 2 - PetAccessor: Bu hizmetler evcil hayvanların toplanmasını sağlar ve doğrulama kontrolleri yapar

Servis 3,4 - Daha fazla ara servis çağrısı

Hizmet 5 - Kullanıcı Etkileşimi

Bunlar çok gelişigüzel ama mesele basit. Kullanıcı arabirimi veya bazı kullanıcılara yönelik hizmet bir şekilde bu "PET" nesnesini sunmak istemektedir. Bir API aracılığıyla, gerekli bilgileri toplayan ve geçişi geri başlatan hizmete ulaşıncaya kadar, hizmeti çağıran, hizmeti çağıran vb. Bir hizmeti çağırmalıdır. Son olarak UI hizmetinde görüntülenecek PET nesnesi bulunur.

Bu oldukça yaygın - ama mutlak anlayışımızla PET nesnesini her hizmette çoğalttık. KURU (kendinizi tekrarlamayın) ilkesi yalnızca bir hizmetin İÇİNDEKİ kodu için geçerlidir ve hizmetler arasında geçerli değildir, ancak nokta hala oradadır. Bir alan eklersek ... her birinde 5 POJO hizmetini değiştirmeliyiz.

--VEYA-- Biz API bazı pojo içeren içeren bir Pet-Objects-Library sağlayabilir ve her hizmet kütüphaneye alabilir / bağımlılık. Hizmetlerin kendilerine bağımlılık yoktur, sadece genel kütüphanedir. Bu fikri beğendim, böylece her hizmet aynı türde nesneye sahip ve güncellemeler daha kolay. Ama ben Tanrı-Objeleri hakkında endişeliyim.

Pro / con nedir - en iyi tasarım nedir? Aynı POJO sınıflarını tekrarlamayı en aza indirgemek ve aynı zamanda bağlı kalmamak için hizmetler arasında veri aktarmak için ne yaptınız?

En iyi tasarım nedir?

Aynı Pet DTO nesnesini (tipik iş mantığını işleyen) arka uç hizmetleri arasında yeniden kullanabilirsiniz , ancak sunum katmanı (Kullanıcı Arayüzü) söz konusu olduğunda, genellikle bir FormBean (ek alanları olan farklı bir fasulye) kullanmak iyi bir uygulamadır sunum mantığı için), böylece sunum mantığı ile iş mantığı arasında açık bir ayrım olacaktır .

Bu, hizmetlerin yeniden kullanılabilir olması ve tek bir hizmetin birden çok / farklı uç noktalarla (ön uç gibi veya farklı bir web hizmeti vb. Olabilir) açığa çıkarılabileceği / yeniden kullanılabileceği ve bu uç noktaların her birinin, ilgili Kontrolörler veya katmanlar (adaptörler gibi) üzerinde.

Aynı POJO sınıflarını tekrarlamayı en aza indirgemek ve aynı zamanda bağlı kalmamak için hizmetler arasında veri aktarmak için ne yaptınız?

İş ve web katmanları arasında tek bir fasulye kullanıyorsanız , sunum mantığını iyi bir uygulama olmayan iş mantığıyla sıkıca bağlarsınız ve hizmetleri Ön Uçtaki bir gereksinim için değiştirirsiniz (örneğin, farklı bir tarih biçimi gibi) Kullanıcı Arayüzünde gösterilmesi). Ayrıca, verileri çekirdekler arasında doldurma / kopyalama işlemini yapmak için (DTO'dan FormBean veya Viceversa'ya gibi), kaynak plakası kodundan kaçınmak için Apache BeanUtils.copyProperties() veya Dozer gibi kütüphaneleri kullanabilirsiniz .

DTO tüm mikro hizmetlerde aynı işletmeyi temsil ediyorsa, hizmetler arasında paylaşılan sadece bir sınıf olmalıdır. Aynı nesne için yinelenen kod bulunması (neredeyse) hiçbir zaman doğru değildir.

Şimdi nasıl yapmayı planladığımın yolu, her hizmetin yalnızca DTO'ları paketlemesi ve jar lib olarak Nexus'a koymasıdır. Diğer hizmetlerin bunlara ihtiyacı olduğunda, bu DTO lib (lar) ı manve / gradle bağımlılığı olarak alacaktır. Bir hizmette yeni DTO sürümü yayınlanırsa, eski sürüm olduğu sürece aynı zamanda da desteklenir, bu nedenle geriye dönük uyumluluk, sürüm oluşturma vb. Ayrıca çevresel bağımlılığı önlemek için hizmeti dto ambalajından ayırmak daha iyidir

Şimdi arka uçtan uca bakın ve tam tersi , sunum katmanı olarak kullanıcı arayüzünün farklı olduğu önceki yorumlara katılmıyorum. O DEĞİL!!! Kullanıcı arayüzü, olayları da tüketen ve üreten bir başka mikro hizmettir.

Arka uçtan öne yönlendirme Yaptığım şey POJO'yu (dtos) Typcriptcript arayüzlerine ve pakete NPM'ye dönüştürmek ve Nexus'a yüklemek. UI nodejs tabanlı proje daha sonra bunları tüketir ve kullanır. Bu UI için yol hizmetidir.

Ön uçtan arka uca yön UI'den hizmet katmanı olaylarına hizmet etmek için Typcript arabirimlerini dönüştürür ve POJO'lara (dtos) dönüştürür, kavanoz olarak paketler ve arka uç hizmetleri tarafından tüketilecek kavanoz biçiminde Nexus'a (veya bazı repo) yüklerim.

Bu süreçler CI süreçleri (Travis, Gitlab CI, vb.) Tarafından kolayca halledilir.

Bu yaklaşımla ilgili herhangi bir yorum memnuniyetle karşılandı.