Birisi alan adı ve uygulama hizmetleri arasındaki farkı bazı örnekler vererek açıklayabilir mi? Bir hizmet bir etki alanı hizmetiyse, bu hizmetin gerçek uygulamasını etki alanı derlemesi içine yerleştirir miyim ve öyleyse, bu etki alanı hizmetine de depolar ekleyebilir miyim? Bazı bilgiler gerçekten yardımcı olur.
Yanıtlar:
Hizmetler 3 çeşittir: Etki Alanı Hizmetleri , Uygulama Hizmetleri ve Altyapı Hizmetleri .
Etki Alanı Hizmetlerini Etki Alanı Nesnelerinizle birlikte tutmak mantıklıdır - hepsi etki alanı mantığına odaklanmıştır. Ve evet, Hizmetlerinize Depolar enjekte edebilirsiniz.
Uygulama Hizmetleri genellikle Alan Adı Hizmetleri hem kullanacaktır ve dış istekleri ile başa çıkmak için Depolarını.
Umarım yardımcı olur!
(Okumak istemiyorsanız, altta bir özet var :-)
Ben de uygulama hizmetlerinin kesin tanımıyla mücadele ettim. Vijay'ın cevabı bir ay önce düşünme sürecime çok yardımcı olmasına rağmen, bunun bir kısmına katılmıyorum.
Uygulama hizmetleri hakkında çok az bilgi var. Toplam kökler, depolar ve alan hizmetleri gibi konular kapsamlı bir şekilde tartışılmaktadır, ancak uygulama hizmetleri sadece kısaca belirtilir veya tamamen dışarıda bırakılır.
Etki Alanına Dayalı Tasarıma Giriş MSDN Dergisi makalesi , uygulama hizmetlerini etki alanı modelinizi harici istemcilere dönüştürmenin ve / veya bir WCF hizmeti gibi dış istemcilere sunmanın bir yolu olarak açıklamaktadır. Vijay uygulama hizmetlerini de bu şekilde tanımlıyor. Bu açıdan, uygulama hizmetleri alan adınız için bir arayüzdür .
Soğan Mimarlık Jeffrey Palermo'nun makaleleri (bölüm tek , iki ve üç ) iyi bir okuma vardır. Uygulama hizmetlerini , kullanıcının oturumu gibi uygulama düzeyinde kavramlar olarak görür. Bu, uygulama hizmetleri anlayışımla daha yakın olsa da, konu hakkındaki düşüncelerimle hala uyumlu değil.
Uygulama hizmetlerini , uygulamanın sağladığı bağımlılıklar olarak görmeye başladım . Bu durumda, uygulama bir masaüstü uygulaması veya bir WCF hizmeti olabilir.
Bir örnekleme zamanı. Etki alanınızla başlarsınız. Dış kaynaklara bağımlı olmayan tüm varlıklar ve etki alanı hizmetleri burada uygulanır. Dış kaynaklara bağımlı etki alanı kavramları bir arabirim tarafından tanımlanır. İşte olası bir çözüm düzeni (proje adı kalın harflerle gösterilmiştir):
Çözümüm
- My.Product.Core (My.Product.dll)
- DomainServices
IExchangeRateService
Ürün
ProductFactory
IProductRepository
ProductVe ProductFactorysınıfları çekirdek düzeneği içinde uygulanmıştır. IProductRepositoryMuhtemelen bir veritabanı tarafından desteklenmektedir şeydir. Bunun uygulanması alanın endişesi değildir ve bu nedenle bir arayüz tarafından tanımlanır.
Şimdilik IExchangeRateService,. Bu hizmetin iş mantığı harici bir web hizmeti tarafından uygulanır. Bununla birlikte, kavramı hala alanın bir parçasıdır ve bu arayüzle temsil edilmektedir.
Dış bağımlılıkların uygulanması, uygulamanın altyapısının bir parçasıdır:
Çözümüm
+ My.Product.Core (My.Product.dll)
- My.Product.Infrastructure (My.Product.Infrastructure.dll)
- DomainServices
XEExchangeRateService
SqlServerProductRepository
XEExchangeRateServiceuygular IExchangeRateServiceile iletişim kurarak alanı hizmeti xe.com . Bu uygulama, altyapı derlemesini ekleyerek etki alanı modelinizi kullanan uygulamalarınız tarafından kullanılabilir.
Henüz uygulama hizmetlerinden bahsetmediğimi unutmayın. Şimdi bunlara bakacağız. IExchangeRateServiceHızlı aramalar için önbellek kullanan bir uygulama sunmak istediğimizi varsayalım . Bu dekoratör sınıfının ana hatları şöyle görünebilir.
public class CachingExchangeRateService : IExchangeRateService
{
private IExchangeRateService service;
private ICache cache;
public CachingExchangeRateService(IExchangeRateService service, ICache cache)
{
this.service = service;
this.cache = cache;
}
// Implementation that utilizes the provided service and cache.
}
ICacheParametreye dikkat edin mi? Bu konsept alan adımızın bir parçası değildir, dolayısıyla bir alan adı hizmeti değildir. Bu bir uygulama hizmetidir . Uygulama tarafından sağlanabilecek altyapımızın bağımlılığıdır. Bunu gösteren bir uygulama sunalım:
Çözümüm
- My.Product.Core (My.Product.dll)
- DomainServices
IExchangeRateService
Ürün
ProductFactory
IProductRepository
- My.Product.Infrastructure (My.Product.Infrastructure.dll)
- Uygulama Hizmetleri
ICache
- DomainServices
CachingExchangeRateService
XEExchangeRateService
SqlServerProductRepository
- My.Product.WcfService (My.Product.WcfService.dll)
- Uygulama Hizmetleri
MemcachedCache
IMyWcfService.cs
+ MyWcfService.svc
+ Web.config
Tüm bunlar böyle uygulamada bir araya geliyor:
// Set up all the dependencies and register them in the IoC container.
var service = new XEExchangeRateService();
var cache = new MemcachedCache();
var cachingService = new CachingExchangeRateService(service, cache);
ServiceLocator.For<IExchangeRateService>().Use(cachingService);
Tam bir uygulama üç ana katmandan oluşur:
Etki alanı katmanı, etki alanı varlıklarını ve tek başına etki alanı hizmetlerini içerir. Dış kaynaklara bağımlı olan tüm etki alanı kavramları (bu etki alanı hizmetlerini içerir, ancak havuzları da içerir) arabirimler tarafından tanımlanır.
Altyapı katmanı, arayüzlerin etki alanı katmanından uygulanmasını içerir. Bu uygulamalar, uygulama sağlanması gereken yeni etki alanı dışı bağımlılıklar getirebilir . Bunlar uygulama hizmetleridir ve arabirimlerle temsil edilir.
Uygulama katmanı, uygulama hizmetlerinin uygulanmasını içerir. Altyapı katmanı tarafından sağlanan uygulamalar yeterli değilse, uygulama katmanı ek alan arayüzleri uygulamaları da içerebilir.
Bu perspektif, hizmetlerin genel DDD tanımıyla eşleşmese de, etki alanını uygulamadan ayırır ve etki alanı (ve altyapı) derlemesini çeşitli uygulamalar arasında paylaşmanıza olanak tanır.
IExchangeRateServiceArayüz mü demek istediniz ? Bu bir alan adı konseptidir, yani müşterinizin her yerde bulunan diline eklenmiş bir şeydir. Alan adınızın diğer bölümleri bu hizmete bağlı olabilir, bu nedenle arayüzünün alan adı katmanında tanımlandığı anlamına gelir. Ancak uygulaması harici bir web hizmeti içerdiğinden, uygulayıcı sınıf altyapı katmanında bulunur. Bu şekilde etki alanı katmanı yalnızca iş mantığı ile ilgilidir.
ExchangeRate, bir temel para birimi, bir karşı para birimi ve bu iki para birimi arasındaki döviz kuru değerini içeren bir örnek olabilir . Sıkı ilişkili olan bu değerler, alan adından gelen 'döviz kuru' kavramını temsil eder, bu nedenle bunlar alan adı katmanında yaşar. Basit bir DTO gibi görünse de, DDD'de buna Değer Nesnesi denir ve örnekleri karşılaştırmak veya dönüştürmek için ek iş mantığı içerebilir.
Bir Uygulama Hizmeti ile Etki Alanı Hizmeti arasındaki farkı anlamama yardımcı olan en iyi kaynak, burada bulunan Eric Evans'ın kargo örneğinin java uygulamasıydı . Yüklemezseniz, RoutingService'in (bir Etki Alanı Hizmeti) ve BookingService, CargoInspectionService'in (Uygulama Hizmetleri olan) iç kısımlarını kontrol edebilirsiniz.
Benim 'aha' anım iki şeyle tetiklendi:
Yukarıdaki bağlantıda Hizmetlerin açıklamasını okumak, daha doğrusu bu cümle:
Etki alanı hizmetleri her yerde kullanılabilen dil ve etki alanı türleri olarak ifade edilir, yani yöntem bağımsız değişkenleri ve döndürülen değerler uygun etki alanı sınıflarıdır.
Bu blog gönderisini , özellikle bu bölümü okuma :
Elmaları portakallardan ayırmada büyük bir yardım bulduğum, uygulama iş akışı açısından düşünüyor. Uygulama iş akışıyla ilgili tüm mantık genellikle Uygulama Katmanı'na dahil edilen Uygulama Hizmetleri olurken, model nesneleri olarak uymayan etki alanından gelen kavramlar bir veya daha fazla Etki Alanı Hizmeti oluşturur.
Etki alanı hizmeti , etki alanının uzantısıdır. Yalnızca alan adı bağlamında görülmelidir. Bu, örneğin yakın hesap veya benzeri bir kullanıcı eylemi değildir . Etki alanı hizmeti, durumun olmadığı bir yere uyar. Aksi takdirde bir etki alanı nesnesi olur. Etki alanı hizmeti, yalnızca diğer ortak çalışanlarla (etki alanı nesneleri veya diğer hizmetler) yapılırken anlamlı olan bir şey yapar. Ve bu mantıklı olmak başka bir katmanın sorumluluğudur.
Uygulama hizmeti , etki alanı nesneleri ve hizmetleri arasındaki etkileşimi başlatan ve denetleyen katmandır. Akış genellikle şöyledir: etki alanı nesnesini (veya nesnelerini) depodan alın, bir işlemi yürütün ve (onları) oraya koyun (veya etmeyin). Daha fazlasını yapabilir - örneğin bir etki alanı nesnesinin olup olmadığını kontrol edebilir ve buna göre istisnalar atabilir. Böylece, kullanıcının etki alanı nesnelerini ve hizmetlerini değiştirerek uygulama ile etkileşime girmesini sağlar (ve muhtemelen adının kaynağı budur). Uygulama hizmetleri genellikle tüm olası kullanım örneklerini temsil etmelidir. Muhtemelen etki alanını düşünmeden önce yapabileceğiniz en iyi şey, gerçekten yapmaya çalıştığınız şey hakkında size daha iyi bir fikir verecek uygulama hizmeti arabirimleri oluşturmaktır. Böyle bir bilgiye sahip olmak, alan adına odaklanmanızı sağlar.
Depolar genellikle etki alanı hizmetlerine enjekte edilebilir, ancak bu oldukça nadir bir senaryodur. Ancak çoğu zaman bunu yapan uygulama katmanıdır.
Kırmızı Kitaptan (Etki Alanına Dayalı Tasarımın Uygulanması, Vaughn Vernon tarafından), kavramları şu şekilde anlıyorum:
Etki alanı nesneleri ( varlıklar ve değer nesneleri ), (alt) etki alanının gerektirdiği davranışı içine alır, bu da onu doğal, etkileyici ve anlaşılır kılar.
Etki alanı hizmetleri , tek bir etki alanı nesnesine sığmayan bu tür davranışları içerir . Örneğin, bir kredi bir kitap kütüphane Book, bir karşı Client(karşılık gelen Inventorydeğişiklikleri) etki alanı hizmetinden böylece yapabilir.
Uygulama hizmetleri , alan adlarının üstünde ihtiyaç duyulan ek endişeler de dahil olmak üzere kullanım durumlarının akışını ele alır . Harici istemciler tarafından tüketilmek üzere genellikle bu yöntemleri API'sı aracılığıyla ortaya koyar. Önceki örneğimize dayanmak için, uygulama hizmetimiz şu yöntemi ortaya çıkarabilir LendBookToClient(Guid bookGuid, Guid clientGuid):
Client.Book.Clientve ileterek Book) çağırır. Örneğin, kitabın kullanılabilirliğinin onaylanmasının kesinlikle alan mantığının bir parçası olduğunu hayal ediyorum.Bir uygulama hizmetinin genellikle çok basit bir akışı olmalıdır. Karmaşık uygulama hizmeti akışları genellikle etki alanı mantığının etki alanının dışına çıktığını gösterir.
Umarım görebileceğiniz gibi, etki alanı modeli bu şekilde çok temiz kalır ve etki alanı uzmanlarıyla anlaşılması ve tartışılması kolaydır, çünkü yalnızca kendi gerçek iş endişelerini içerir. Uygulama akış , diğer taraftan, bir de o alanı kaygıları rahatlamış olduğundan, yönetmek çok daha kolay ve öz, ve anlaşılır hale gelir.
Etki Alanı Hizmetleri: Tek bir varlığa tam olarak uymayan veya depoya erişim gerektiren yöntemler etki alanı hizmetlerinde bulunur. Etki alanı hizmet katmanı, kendi etki alanı mantığını da içerebilir ve etki alanı modelinin varlık ve değer nesneleri kadar büyük bir parçasıdır.
Uygulama Hizmetleri: Uygulama hizmeti, etki alanı modelinin üzerinde yer alan ve uygulama etkinliğini koordine eden ince bir katmandır. İş mantığı içermez ve herhangi bir varlığın durumunu tutmaz; ancak, bir iş iş akışı işleminin durumunu saklayabilir. Bir Uygulama hizmetini, İstek Yanıtlama ileti desenini kullanarak etki alanı modeline API sağlamak için kullanırsınız.
Millett, C (2010). Profesyonel ASP.NET Tasarım Desenleri. Wiley Yayıncılık. 92.
Etki Alanı Hizmetleri : Herhangi bir Toplam Kökün parçası olmayan bir iş mantığını ifade eden hizmet .
2 Topluluğunuz var:
Product adı ve fiyatı içerir.Purchase satın alma tarihini, o sırada miktar ve ürün fiyatı ile sipariş edilen ürünlerin listesini ve ödeme yöntemini içerir.Checkout bu iki modelin her ikisinin bir parçası değildir ve işinizdeki kavramdır.
Checkouttüm ürünü getiren ve toplam fiyatı hesaplayan, toplamı PaymentService, Altyapının bir uygulama bölümü olan başka bir Etki Alanı Hizmeti'ni çağırarak ödeyip bir alana dönüştüren bir Etki Alanı Hizmeti olarak oluşturulabilir Purchase.Uygulama Hizmetleri : Etki Alanı yöntemlerini "düzenleyen" veya kullanan bir hizmet . Bu sadece Kontrolörünüz kadar basit olabilir.
Burası genellikle yaptığınız yer:
public String createProduct(...some attributes) {
if (productRepo.getByName(name) != null) {
throw new Exception();
}
productId = productRepository.nextIdentity();
product = new Product(productId, ...some attributes);
productRepository.save(product);
return productId.value();
// or Product itself
// or just void if you dont care about result
}
public void renameProduct(productId, newName) {
product = productRepo.getById(productId);
product.rename(newName);
productRepo.save(product);
}
A'nın Productbenzersiz olup olmadığını kontrol etmek gibi burada doğrulama yapabilirsiniz . ProductBenzersiz bir varlık değişmezse, o zaman etki alanı hizmetinin bir parçası olmalıdır UniqueProductCheckerçünkü Productsınıfın bir parçası olamaz ve birden fazla Toplama ile etkileşime girer.
İşte DDD projesinin tam örneği: https://github.com/VaughnVernon/IDDD_Samples
Çok sayıda Uygulama Hizmeti ve birkaç Etki Alanı Hizmeti örneği bulabilirsiniz.
Etki Alanı Hizmetini , etki alanı nesnelerinde iş mantığını veya iş kurallarıyla ilgili mantığı uygulayan bir nesne olarak düşünün ve bu mantığın aynı etki alanı nesnelerine sığması zordur ve ayrıca etki alanı hizmetinin durum değişikliğine neden olmaz (etki alanı hizmeti, ticari anlamı olan bir durum olmadan "durum" veya daha iyisi), ancak sonunda yalnızca üzerinde çalıştığı alan nesnelerinin durumunu değiştirin.
Bir Uygulama Hizmeti , kullanıcı etkileşimi, giriş doğrulama, işle ilgili değil, diğer endişelerle ilgili mantık olarak uygulanabilir düzey mantığını uygularken, kimlik doğrulama, güvenlik, e-posta gönderme vb.
Bunun bir örneği, yalnızca amacı açıklamak için düşünülen aşağıdaki senaryo olabilir: basit bir işlemi yürüten çok az bir domotik yardımcı uygulama uygulamalıyız, yani birisi bir evin odasının kapısını açtığında ışıkları açın "ve odadan çıkan kapıyı kapattığında ışığı kapatın" + + msgid ".
Çok basitleştirmek için sadece 2 alan varlığını düşünüyoruz: Doorve Lampher birinin 2 durumları var, sırasıyla open/closedve on/offbunlarda durum değişikliklerini gerçekleştirmek için belirli yöntemler.
Bu durumda, birisi bir odaya girmek için kapıyı dışarıdan açtığında ışığı açma işlemini gerçekleştiren bir etki alanı hizmetine ihtiyacımız vardır, çünkü kapı ve lamba nesneleri bu mantığı uygun olduğunu düşündüğümüz şekilde uygulayamaz. onların doğasına .
Biz bizim etki alanı servisini arayabilirsiniz DomoticDomainService: 2 yöntemlerini uygulamak OpenTheDoorAndTurnOnTheLightve CloseTheDoorAndTurnOffTheLightbu 2 yöntem respectevely hem nesnelerin durumunu değiştirme, Doorve Lampiçin open/onve closed/off.
Etki alanı hizmeti nesnesinde ve etki alanı nesnelerinde bulunmadığı bir odaya giriş veya çıkış durumu, ancak HouseServicebazı olay işleyicilerini şu şekilde uygulayabileceğimiz , arayabileceğimiz bir uygulama hizmeti tarafından basit kullanıcı etkileşimi olarak uygulanacaktır onOpenRoom1DoorToEnterve onCloseRoom1DoorToExitbu şekilde devam eden her oda için (bu sadece amacı açıklamak için bir örnektir ..) , sırasıyla katılan davranışı yürütmek için çağrı etki alanı hizmet yöntemleri hakkında endişe edecektir (biz Roomsadece bir örnek olduğu için varlığı dikkate almadık ) .
Bu örnek, iyi tasarlanmış bir gerçek dünya uygulaması olmak için, bir Alan Hizmetinin ne olduğunu ve bir Uygulama Hizmetinden farkını açıklamanın tek amacına sahiptir (daha çok kez söylendiği gibi), açık ve yararlı olduğunu umuyoruz.