Uygulama katmanı vs etki alanı katmanı?

Domain Tarafından Yönlendirilmiş Tasarım'ı Evans'dan okuyorum ve katman mimarisini tartışan bölümdeyim. Uygulama ve etki alanı katmanlarının farklı olduğunu ve ayrı olması gerektiğini fark ettim. Üzerinde çalıştığım projede biraz harmanlanmışlar ve kitabı okuyana kadar aradaki farkı söyleyemem (ve şimdi bana çok açık olduğunu söyleyemem).

Sorumlarım, ikisi de uygulamanın mantığını ilgilendirdiği ve teknik ve sunum yönlerinden temiz olması gerektiği için, bu ikisinin sınırlarını çizmenin avantajları nelerdir?

Geçenlerde DDD'yi kendim okudum. Bu bölüme geldiğimde, Evans'ın yaptığı aynı 4 katlı mimariyi keşfettim. @ Lonelybug'un işaret ettiği gibi, alan katmanı sistemin geri kalanından tamamen izole edilmelidir. Ancak, bir şeyin UI'ye özgü değerleri (sorgu dizeleri, POST verileri, oturum vb.) Etki alanı nesnelerine dönüştürmesi gerekir. Uygulama katmanı devreye giriyor. Görevi, kullanıcı arabirimini, veri katmanını ve etki alanını ileri geri çevirmek, etki alanını sistemin geri kalanından etkin şekilde gizlemektir.

Hemen hemen tüm mantığın denetleyicilerde olduğu bir çok ASP.NET MVC uygulaması görüyorum. Bu, klasik 3 katmanlı mimariyi uygulamak için başarısız bir girişimdir. Kontrolörlerin ünite testi yapmaları zordur, çünkü kullanıcı arayüzüne özgü çok fazla endişeleri vardır. Aslında, bir denetleyiciyi "Http Bağlamı" değerleri ile doğrudan ilgilenmeyecek şekilde yazmak, kendi başına ciddi bir sorundur. İdeal olarak kontrolör sadece çeviri yapmalı, işi koordine etmeli ve cevabı geri vermelidir.

Uygulama katmanında temel doğrulama yapmak bile mantıklı gelebilir. Etki alanının kendisine giren değerleri kabul etmesi tamamdır (bu, bu müşteri için geçerli bir kimliktir ve bu dize bir tarih / saati temsil ediyor mu). Ancak, iş mantığını içeren doğrulama (geçmişte bir uçak bileti alabilir miyim?) Etki alanı katmanı için ayrılmalıdır.

Martin Fowler aslında çoğu etki alanı katmanının bugünlerde ne kadar düz olduğu konusunda yorum yapıyor . Çoğu kişi bir uygulama katmanının ne olduğunu bile bilmese de, birçok insanın farklı alan nesnelerinin çalışmasını koordine eden oldukça aptal alan nesneleri ve karmaşık uygulama katmanları yaptığını bulur. Bundan kendimi suçluyorum. Önemli olan bir katman oluşturmak değildir, çünkü bazı kitaplar size söylemiştir. Fikir, sorumlulukları tanımlamak ve bu sorumluluklara dayanarak kodunuzu ayırmaktır. Benim durumumda, "uygulama katmanı" tür bir ünite testini arttırdıkça doğal olarak gelişti.

Martin Fowler'in kurumsal tasarım modellerinden yola çıkarak en yaygın katmanlar şunlardır:

• Sunum - bunlar görünümler, uygulamanız için etkileşim arayüzünü oluşturan sunum şablonları (uygulamanıza web servisleri veya RMI aracılığıyla diğer sistemler tarafından erişilebiliyorsa etkileşimi kullanıyorum, bu yüzden kullanıcı arayüzü olmayabilir). Bu aynı zamanda eylemlerin nasıl yürütüleceğine ve nasıl uygulanacağına karar veren denetleyicileri de içerir.

• Etki alanı - iş kurallarınızın ve mantığınızın bulunduğu yer, etki alanı modelleriniz vb.

• Veri Kaynağı - bu veri haritalama katmanı (ORM) ve veri kaynağıdır (veritabanı, dosya sistemi vb.)

Üç katman arasındaki sınırları nasıl çizersiniz:

• Sunuma özel bir mantık modeli veya etki alanı nesnelerine koymayın

• Sayfalarınıza ve denetleyicilerinize mantık koymayın, yani nesneleri veritabanına kaydetmeyi, veritabanı bağlantılarını oluşturmayı vb. Sunum katmanınızı kırılgan ve test etmesini zorlaştırır

• Veri kaynağı erişiminizi ve modelden eylemlerinizi ayırmanıza olanak sağlayan bir ORM kullanın.

• İnce denetleyiciyi takip edin - yağ modeli paradigması, denetleyiciler daha fazla değil, yürütme işlemini kontrol etmek içindir, daha fazlası için : ve http://weblog.jamisbuck.org/2006/10/18/skinny-controller-fat-model model, görünüm ve denetleyici,

Etki alanı katmanı , uygulamanızın işini modeller . Bu, onun kuralları, bileşen dinamikleri ve herhangi bir anda durumunu içeren açık bir şekilde yorumlanmalıdır.

Uygulama katmanı belli uygulama görevi başarmak için yapılması gereken işleri tanımlayan "endişe" olduğunu. Esas olarak, gerekli etki alanı çalışmasının görevlendirilmesinden sorumludur ve diğer (harici veya değil) hizmetlerle etkileşime girer.

İçin örneğin , benim mali yazılım uygulaması örnek bir varlık durumunu değiştirmek için bir kullanıcı işlemi vardır (DDD tanımlanan varlık [89]):

• "Operasyon şefi bir finansal teklifi onaylayabilir".

Ancak, başvuru süreci olarak, bu işlemin tüm model sonuçlarının yanı sıra, uygulamanın diğer kullanıcılarına da dahili bir iletişim göndermem gerekiyor. Bu tür bir çalışma, uygulama katmanında "yönetilmektedir". Etki alanı katmanımın bir mesajlaşma servisini yönlendirmeyi düşünmesini istemem. (ve bu kesinlikle bir sunum katmanı sorumluluğu değil). Her ne şekilde olursa olsun, kesin olan bir şey var: Etki alanı katmanım tamamen temel işle ilgili olduğundan ve sunum katmanım da kullanıcı komutlarını yorumlama ve sonuçları sunma ile ilgili olduğu için yeni bir katmana ihtiyacım var.

Notlar:

• İş , sıklıkla anlamının birçok yorumuna yol açan bu kelimelerden biridir, ancak DDD'de pek çok örnek bulabilir ve konuşabilirsiniz;
• DDD, Eric Evans'ın Domain-Driven Tasarım kitabı ve sayfa numarası için köşeli parantez içindeki sayı anlamına gelir.

Etki Alanı Katmanı, bir yalıtım katmanı olarak tasarlanmalıdır; bu, iş mantığının ve kuralların (Uygulama Katmanı, Sunum Katmanı ve Altyapı Katmanı'nda) değişikliklerden etkilenmemesi gerektiği anlamına gelir.

Uygulama Katmanı, bir sistem (uygulama) arabiriminin (bir API veya RESTful gibi olduğunu düşünebilirsiniz) yapabilecekleriyle ilgili bazı işlevler sağlayacak şekilde tasarlandığını varsayar. Örneğin, kullanıcılar bir sisteme giriş yapabilir ve bu uygulama eyleminde (giriş), uygulama katmanı kodları, Kullanıcı etki alanı nesnesini alan ve bu nesnenin uygulama yöntemlerini uygulayan Etki Alanı Katmanı (veya Altyapı Katmanı) için istemci kodları olur. 'giriş' işlevi.

Uygulama Katmanı ayrıca bir yalıtım katmanı olarak da tasarlanmalıdır; bu, uygulamanın davranışlarının herhangi bir koddan (Sunum Katmanı, Etki Alanı Katmanı ve Altyapı Katmanı'nda) değişikliklerden etkilenmemesi gerektiği anlamına gelir.

Etki Alanına Dayalı Modelleme'nin amacı, temel etki alanı modelini ayırmak ve diğer katmanlara ve diğer uygulama endişelerine bağımlı olmadan var olmasını sağlamaktır.

Bu, dikkat dağıtıcı olmadan etki alanının kendisine odaklanmanıza olanak tanır (örneğin, kullanıcı arayüzü ve ısrar hizmetleri arasında koordine etmek gibi).

• Uygulama Katmanı ve Etki Alanı Katmanı hem uygulama kapsamına girer.
• Uygulama Katmanı , API gibi davranır.
• Etki Alanı Katmanı , bir API uygulaması olarak işlev görür, iş mantığı içerir, bu nedenle İş Mantığı Katmanı olarak da adlandırılır .

Bu sınırların temel nedeni endişelerin ayrılmasıdır . Veri deposuna erişen kodun yalnızca veri deposuna erişme konusunda endişelenmesi gerekir. Verilere kural uygulamaktan sorumlu olmamalıdır. Ek olarak, UI, UI'daki kontrolleri güncellemekten, kullanıcı girişinden değer elde etmekten ve bunları etki alanı katmanının kullanabileceği bir şeye çevirmekten ve daha fazlasını yapmaktan sorumlu olmalıdır. Gerekli işlemleri yapmak için etki alanı katmanı tarafından sağlanan işlemleri çağırmalıdır (örn. Bu dosyayı kaydedin). Çağrılan bir web hizmetinin iletim ortamından etki alanı katmanının kullanabileceği bir şeye dönüştürülmesinden sorumlu olması ve ardından etki alanı katmanını çağırması gerekir (çoğu araç sizin için bu işin çoğunu yapar).

Bu ayırım, doğru bir şekilde uygulandığında, kodunuzun bölümlerini başkalarını etkilemeden değiştirebilmenizi sağlayabilir. Örneğin, belki de iade edilen bir nesne koleksiyonunun sıralama düzeni değişmelidir. Veri manipülasyonundan sorumlu olan katmanın (genellikle iş mantığı katmanı) bunları işlediğini bildiğinizden, kodun nerede değiştirilmesi gerektiğini kolayca belirleyebilirsiniz. Veri deposundan veya etki alanını kullanan uygulamalardan herhangi birinin (yukarıdaki örneğimden UI ve web hizmeti) nasıl alınacağının değiştirilmesinin yanı sıra.

Nihai amaç, kodunuzu mümkün olduğunca kolay muhafaza etmektir.

Bir yan not olarak, bazı şeyler alanın belirli bir katmanına (örn. Günlüğe kaydetme, doğrulama ve yetkilendirme) güvercin bağlantısı yapılamaz. Bu öğeler genellikle enine kesen kaygılar olarak adlandırılır ve bazı durumlarda diğer tüm katmanların görebileceği ve kullanabileceği bir katman olarak ele alınabilir.

Şahsen katmanlı yaklaşımın modası geçmiş olduğunu ve hizmet yaklaşımının daha iyi olduğunu düşünüyorum. Hala kim ne yaptığını kuma çizilen keskin çizgiye sahipsin, ama seni hiyerarşik olmaya zorlamıyor. Örneğin, bir satınalma siparişi hizmeti, bir faturalama hizmeti ve bir nakliye hizmeti, uygulama açısından tüm bu hizmetlerin etki alanınızı temsil ettiği ve yukarıda açıklanan sorumluluğumun ertelenmesi bu bağlamda hala geçerlidir; etki alanınızın birden fazla yerde bulunduğunu, ayrıca kaygılar kavramının ayrılmasından yararlanın.