Doğası gereği çok modüler olan ve gelecekteki kolay genişleme, endişelerin net bir şekilde ayrılması, modülle lisanslama vb. İçin destek sağlayan bir yapı oluşturmak isteyen yeni bir çözüm tasarlamaya çalışıyorum. modüler veya kompozit uygulamalar hakkında web'de bulunan, Silverlight, WPF, vb. odaklı. Benim durumumda, çeşitli UI projelerinde çalışan diğer geliştiriciler tarafından tüketilecek bir WCF servis uygulaması geliştiriyorum.
Arka fon
Projemin amacı, şu anda yinelenen süreç, kurallar vb. Birçok iş uygulamamızı desteklemek için merkezi bir iş / etki alanı mantığı kaynağı oluşturmaktır. Ve modülerliğin her faydası elde edilemezken, yararlanabileceğimiz bu parçaları kaldıracak bir çerçeve oluşturma fırsatı.
Tasarıma hizmet uygulamasının gösterdiği API'ye bakarak başladım. Hizmetlerin, düşündüğüm modüler hatlar boyunca ayrılabileceği açıktır. Örneğin, müşterileri yalnızca uygulamalarıyla ilgili hizmetleri tüketmek zorunda kalırken, bağlantıyı düşük tutarken API'de yüksek uyum sağlamak için hizmet işlemlerimi gruplandıran FinanceService, InventoryService, PersonnelService vb hizmetlere sahip olacağım.
Daha sonra bu hizmetlerin her biri için MyApp.Finance, MyApp.Inventory, My.Personnel ve benzeri gibi ayrı modüllere sahip olabileceğim bana mantıklı geliyor. Kesişen endişeler ve paylaşılan türler, MyApp paylaşılan derlemesinde olacaktır. Buradan biraz bağlandım.
(Ah, uygulamayı gevşek bir şekilde tutmak için Bağımlılık Enjeksiyonu için bir IoC konteyneri kullanacağımı belirtmeliyim. Hangisinden bahsetmeyeceğim çünkü Pandora'nın kutusunu açmak istemiyorum!)
MyApp.ServiceHost'ta, örneğin FinanceService.svc gibi her bir modüle karşılık gelen bir hizmet ana bilgisayar dosyası (.svc) oluşturacağım. Hizmet ana bilgisayarının, hizmet sözleşmesini tanımlayan arabirimi içeren yapılandırma dosyasındaki bilgilere karşılık gelen hizmet adına ihtiyacı vardır. IoC konfigürasyonu daha sonra kullanılacak arayüzün somut uygulamasını haritalamak için kullanılır.
1. Hizmet katmanı API'yi uygulamalı ve modüllere devredmeli mi veya modüller kendi kendine yetmeli mi (hizmet uygulaması da dahil olmak üzere bu modülle ilgili her şeyi içerdikleri için)?
Soruna yaklaşmanın bir yolu, hizmet sözleşmelerinin uygulanmasını içeren bir MyApp.Services "modülüne" sahip olmaktır. Her hizmet sınıfı, işlem için etki alanı mantığını içeren başka bir uygun mod modülüne devredilir. Örneğin, MyApp.Services içindeki FinanceService WCF sınıfı, işlemi gerçekleştirmek için Finans modülünde uygulanan başka bir arabirime delege eder. Bu, ince bir hizmet cephesini korumamı ve uygulamayı hizmet uygulamasına 'ekleyebilmemi' ve modüllerin WCF hakkında endişelenme ihtiyacını ortadan kaldırmamı sağlayacaktır.
Öte yandan, belki de her bir modülün arayüze ve uygulamaya sahip olması nedeniyle kendi içinde yer alması tercih edilir. Servis ana bilgisayarı, modülde bulunan servis sözleşmesi arayüzüne atıfta bulunur ve IoC, modülden de uygun uygulamayı kullanacak şekilde yapılandırılır. Bu, yeni bir modül eklemenin, hizmet katmanında yeni bir .svc dosyası ve IoC yapılandırma bilgileri eklemek dışında hiçbir değişiklik yapılmadan yapılabileceği anlamına gelir.
Standart WCF'den RESTful servis arayüzüne geçersem veya belki de RIA servislerine ya da başka bir şeye gidersem bu etkiyi düşünüyorum. Her modül hizmet sözleşmesinin uygulanmasını içeriyorsa, hizmet teknolojisini veya yaklaşımını değiştirirsem her modülde değişiklik yapmam gerekir. Ancak, cephe kendi modülü ise, o zaman sadece bir değişiklik yapmak için o parçayı değiştirmem gerekir. Modüller daha sonra, muhtemelen paylaşılan montajda tanımlanan farklı bir dizi sözleşme (arayüz) uygulamak zorunda kalacaklardır ???
2. Modüller arasındaki kaynakları ve / veya modüller arasındaki bağımlılıkları paylaşmanın en iyi yolu nedir?
Örneğin, bir Alma işlemini ele alalım. İlk allık, mal almak bir envanter fonksiyonu olduğu için bunun Envanter modülüne girmesi mantıklıdır. Bununla birlikte, bir Makbuz oluşturmamız ve ödemeyi yetkilendirmemiz gereken finansal bir husus da vardır.
Bir yandan, operasyonu iletmek için bir tür etki alanı olayı / mesajı kullanmayı beklerdim. Envanter modülü, Makbuz oluşturmak ve ödeme işlemini başlatmak için Financial modülü tarafından işlenen GoodsReceivedEvent öğesini yükseltir. Ancak, bu, Finansal modülün alınan envanter kalemleri hakkında bilgi sahibi olması gerektiği anlamına gelir. Onlara sadece ID ile başvurabilirim, ancak Makbuz için ad ve / veya açıklama, birim maliyet vb. Gibi ek bilgilere ihtiyacım olursa? Her modülün, o modülün ihtiyaçlarına göre tasarlanmış bir envanter öğesinin kendi sürümüne sahip olması anlamlı mıdır? Bu durumda, Financial modülünün GoodsReceivedEvent'i işlerken kendi stok kalemlerini araması gerekir.
...
Bu örneği bilerek kullandım çünkü çeşitli ERP sistemleri ile çok çalıştım ve bu tür modülerlikle tasarlandıklarını biliyorum - nasıl olduğunu bilmiyorum. Ayrıca yukarıda açıkça bahsetmiyorum, ancak çözümü tasarlarken Domain Driven Design ilkelerini takip etmeyi ve bu tür modülerliğin tam olarak bu alana uyduğuna inanıyorum.
Kafamın etrafına dolanan herhangi bir yardım büyük beğeni topluyor.