डोमेन-संचालित-डिज़ाइन में डोमेन सेवा में व्यवसाय तर्क कैसे जोड़ें?

Question

मेरी परियोजना में, बिजनेस लॉजिक सभी एप्लिकेशन सर्विस में, डोमेन सेवा केवल कुछ इकाई है, जो मुझे बता सकता है या मुझे यह दिखाने के लिए एक उदाहरण दे सकता है कि डोमेन-ड्राइव-डिज़ाइन में डोमेन सेवा में व्यवसाय तर्क कैसे जोड़ें? बहुत धन्यवाद!

अद्यतन

मैं एक साधारण solutation लिखते हैं, इस solutation एक वोट प्रणाली है, solutation मुख्य हिस्सा है:

Vote.Application.Service.VoteService.cs:

namespace Vote.Application.Service 
{ 
    public class VoteService 
    { 
     private IVoteRepository _voteRepository; 
     private IArticleRepository _articleRepository; 

     public VoteService(IVoteRepository voteRepository,IArticleRepository articleRepository) 
     { 
      _voteRepository = voteRepository; 
      _articleRepository = articleRepository; 
     } 

     public bool AddVote(int articleId, string ip) 
     { 
      var article = _articleRepository.Single(articleId); 
      if (article == null) 
      { 
       throw new Exception("this article not exist!"); 
      } 
      else 
      { 
       article.VoteCount++; 
      } 

      if (IsRepeat(ip, articleId)) 
       return false; 

      if (IsOvertakeTodayVoteCountLimit(ip)) 
       return false; 

      _voteRepository.Add(new VoteRecord() 
      { 
       ArticleID = articleId, 
       IP = ip, 
       VoteTime = DateTime.Now 
      }); 

      try 
      { 
       _voteRepository.UnitOfWork.Commit(); 
       return true; 
      } 
      catch (Exception ex) 
      { 
       throw ex; 
      } 
     } 

     private bool IsRepeat(string ip, int articleId) 
     { 
      //An IP per article up to cast 1 votes 
      //todo 
      return false; 
     } 

     private bool IsOvertakeTodayVoteCountLimit(string ip) 
     { 
      //An IP per day up to cast 10 votes 
      //todo 
      return false; 
     } 
    } 
} 

वोट.डोमेन.कंट्रैक्ट.वोटोट रिपोजिटरी.cs:

namespace Vote.Domain.Contract 
{ 
    public interface IVoteRepository 
     : IRepository<VoteRecord> 
    { 
     void Add(VoteRecord model); 
    } 
} 

Vote.Domain.Contract.IArticleRepository.cs:

namespace Vote.Domain.Contract 
{ 
    public interface IArticleRepository 
     : IRepository<Article> 
    { 
     void Add(VoteRecord model); 

     Article Single(int articleId); 
    } 
} 

Vote.Domain.Entities.VoteRecord:

namespace Vote.Domain.Entities 
{ 
    public class VoteRecord 
    { 
     public int ID { get; set; } 

     public DateTime VoteTime { get; set; } 

     public int ArticleID { get; set; } 

     public string IP { get; set; } 
    } 
} 

Vote.Domain.Entities.Article:

namespace Vote.Domain.Entities 
{ 
    public class Article 
    { 
     public int ID { get; set; } 

     public string Title { get; set; } 

     public string Content { get; set; } 

     public int VoteCount { get; set; } 
    } 
} 

मैं व्यवसाय लॉग को स्थानांतरित करना चाहता हूं in.s.service में डोमेन.service (वर्तमान में इस परियोजना नहीं), कौन मेरी मदद कर सकता है? कैसे करना उचित है? बहुत धन्यवाद!

Answer 1

डीडीडी ध्यान केंद्रित कर रहा है कि डोमेन मॉडल को आवश्यकता के साथ फिट करने के लिए कैसे डिजाइन किया जाए, डेटाबेस में स्कीमा इससे कोई फर्क नहीं पड़ता।

यदि आपकी डोमेन इकाई केवल संपत्ति बैग है, तो लगता है कि आप Anemic Model anti-pattern का उल्लंघन कर रहे हैं। व्यापार तर्क डोमेन इकाइयों में होना चाहिए। इसलिए, आपके मामले में, व्यवसाय सेवा को लीक करने के लिए व्यावसायिक सेवा से बचने के लिए। यदि आवश्यक हो तो आपके पास आईपी या अन्य गुणों को स्टोर करने के लिए क्लाइंट नामक एक नया मॉडल हो सकता है।

आसान समझने के लिए, क्या क्लाइंट दिन में सीमा से अधिक है, यह विधि क्लाइंट क्लास में होनी चाहिए। विधि के साथ समान है।

तो, आपके डोमेन वस्तु होना चाहिए:

public class Client 
{ 
    public string Ip { get; set; } 
    // More properties if needed 

    public List<Vote> Votes { get; set; } 

    public bool ExceedLimitInDay() 
    { 
    } 
} 

public class Vote 
{ 
    public int Id { get; set; } 
    public DateTime VoteTime { get; set; } 
    public Article Article { get; set; } 
    public Client { get; set; } 
} 

public class Article 
{ 
    public int Id { get; set; } 
    public string Title { get; set; } 
    public string Content { get; set; } 

    public List<Vote> Votes { get; set; } 

    public bool IsRepeated(string ip) 
    { 
     return Votes.Select(v => v.Client.Ip == ip).Any();  
    } 
} 

नोट: यदि आप सिर्फ वोट तालिका में यह नक्शा, नई तालिका ग्राहक बनाने की जरूरत नहीं है, तो। VoteCount गुण का सवाल है, यह कहने की जरूरत नहीं है क्योंकि आप गिनती आधारित कर सकते हैं वोट

Answer 2

की सूची पर अनुप्रयोग सेवा पर एक नज़र में से मैं यह शायद ही एक अनुप्रयोग सेवा है कहेंगे, यह पहले से ही में एक डोमेन सेवा का एक सा यह समझें कि यह कुछ डोमेन तर्क को कैप्चर करता है (जैसा कि व्यूमोडेल इनपुट लेने और इसे इकाइयों पर मैप करने के विरोध में)। हालांकि आपको बड़ी समस्याएं हैं:

आपके समेकन बंद हैं। आप किसी लेख पर वोट डालने वाले आईपी पते के आस-पास दो आविष्कारों को लागू करना चाहते हैं (एक आईपी केवल प्रति लेख एक बार मतदान कर सकता है, एक आईपी प्रति दिन 10 वोट तक कास्ट कर सकता है)। इस पर नज़र रखने के लिए न तो संज्ञाएं एक अच्छी फिट (लेख, वोट) हैं।

ArticleVotes व्यक्तिगत ips द्वारा लेख पर वोट डालने और लागू करने के लिए एक अच्छा फिट हो सकता है, जबकि आईपीवीट्सपेरडेट प्रति दिन आधार पर किसी व्यक्तिगत आईपी पते द्वारा वोटों की संख्या को ट्रैक कर सकता है। यदि आप वोटों की कुल संख्या पर्याप्त कम हैं (और आप प्रदर्शन को तब तक रख सकते हैं जहां आप इसे चाहते हैं) आप ArticleVotes को अनुच्छेद में स्थानांतरित करने में सक्षम हो सकते हैं। IPVotesPerDate को वोटपेरडेट में घुमाया जा सकता है यदि दिन के आधार पर मतदान करने वाले आईपी की कुल संख्या कम है।

नीचे की रेखा यह है कि आईपी और मतदान मात्रा आपके योग के प्रदर्शन को निर्देशित करने जा रही है। यह आपको उन प्रदर्शन संख्याओं को समायोजित करने के लिए पुनर्निर्मित करने के लिए मजबूर कर सकता है जो आप चाहते हैं। आपका सबसे अच्छा शॉट उन नंबरों को जानने के लिए है कि किस दिशा में आगे बढ़ना है।

वहां से यह स्पष्ट होना चाहिए कि वांछित व्यवहार का उल्लेख मैंने समेकित किया जा सकता है। इसलिए, एक डोमेन सेवा की आवश्यकता दूर हो सकती है। मैं कह सकता हूं, क्योंकि उपयोग का मामला अभी भी एक लेख पर एक आईपी कास्टिंग कास्टिंग कर रहा है। ऐसे में जो समेकन में कुछ समन्वय की आवश्यकता हो सकती है, एक डोमेन सेवा की शुरूआत से गुजरना पड़ता है।

Answer 3

मुझे लगता है कि वोट और आलेख एक कुल हैं। मुझे आपके डोमेन के बारे में बहुत कुछ पता नहीं है, लेकिन मुझे लगता है कि प्रत्येक वोट केवल एक दिए गए आलेख के लिए महत्वपूर्ण है। वोट लेखों में साझा नहीं किए जाएंगे, इसलिए उन्हें एकत्रीकरण के सदस्य के रूप में माना जाना चाहिए, और पूरे डोमेन की संस्थाओं के रूप में नहीं माना जाना चाहिए।

मेरी राय में, अनुच्छेद कुल की मूल इकाई होगी और वोट अंदर एक सदस्य इकाई होगी। इस "पैटर्न" को लागू करने से आप अंदर सभी व्यावसायिक तर्क को समाहित कर सकते हैं।

आपके पास अपने लेख के अंदर एक AddVote (...) हो सकता है, या इस तरह के कुछ व्यवसाय तर्क।

तो आप सोच रहे होंगे .. "ठीक है .. लेकिन दृढ़ता के बारे में क्या ??"। चूंकि आप अपने अनुच्छेद-वोट को कुल के रूप में परिभाषित कर रहे हैं, तो आप उन्हें एक साथ व्यवहार करेंगे। यदि आप किसी अनुच्छेद में सीआरयूडी संचालन करते हैं, तो साथ ही आप इन परिचालनों को अपने कुल सदस्यों (वोट) में निष्पादित करेंगे। तो आपको ArticleAggregate के लिए एक भंडार की आवश्यकता हो सकती है, यह लेख के वोटों का ख्याल रखेगी।

आशा है कि यह आपको समझ में आएगा। अपने डोमेन के आधार पर सबसे अच्छा विकल्प चुनें।