स्वच्छ वास्तुकला - रॉबर्ट मार्टिन - केस ग्रैन्युलरिटी

Question

का उपयोग करें, मैं एक परियोजना में रॉबर्ट मार्टिन के Clean Architecture को लागू करने पर विचार कर रहा हूं और मैं यह पता लगाने की कोशिश कर रहा हूं कि गैर-तुच्छ उपयोग के मामलों को कैसे संभाला जाए।

मुझे जटिल/रचनाकृत उपयोग मामलों में आर्किटेक्चर को स्केल करना मुश्किल लगता है, विशेष रूप से उन मामलों का उपयोग करें जहां अभिनेता किसी उपयोगकर्ता के विपरीत सिस्टम है, क्योंकि सिस्टम में कुछ प्रकार की बैच प्रोसेसिंग होती है।

समझाने के उद्देश्य से लिए, हम एक का उपयोग मामला मान की तरह

class UpdateAllAccountBalancesInteraction { 
    function Execute() { 
     Get a list of all accounts 
     For each account 
      Get a list of all new transactions for account 
      For each transaction 
       Perform some specific calculation on the transaction 
      Update account balance 
    } 
} 

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

कुछ सवाल उठता है:

• उपयोग के मामले है एक व्यवसाय के भावी इसे से भी एक वैध उपयोग के मामले "सिस्टम सभी खाते में शेष राशि अपडेट हो जाता है" या इसे छोटा उपयोग के मामलों में टूट जाना चाहिए (हालांकि ऐसा लगता है, यह वैध व्यावसायिक परिदृश्य है)?
• अद्यतनअॉलएक्साउंटबैलेंसइंटरेशन एक वैध बातचीत है?
• क्या अन्य बातचीत को ऑर्केस्ट्रेट करने की अनुमति/बातचीत की अनुमति है?
• क्या कोड है जो अन्य इंटरैक्शन को कहीं और से संबंधित करता है?
• यह सिर्फ एक बातचीत के रूप में UpdateAllAccountBalancesInteraction के लिए ठीक है, लेकिन यह कॉल कार्यों बल्कि अन्य interactors के वाद्यवृन्दकार के रूप में कार्य के अलावा अन्य interactors द्वारा साझा किया है?

Answer 1

स्पष्ट रूप से, आपके पास उच्च स्तरीय इंटरैक्शन के लिए एक नया है जो कम स्तर पर इंटरैक्शन के साथ कुछ (या बहुत सी) सामान्य कार्यक्षमता साझा करता है। यह ठीक है।

यदि व्यापार को UpdateAllAccountBalances नामक उपयोग केस की आवश्यकता होती है, तो यह एक वैध उपयोग केस है, और यह अच्छा है कि आप इसे ऐसे तरीके से नाम दे रहे हैं जो व्यापार तर्क को दर्शाता है।

यह ओ.के. है। अन्य बातचीत को कॉल करने के लिए एक बातचीत के लिए, यदि यह आपके व्यापार तर्क को सटीक रूप से दर्शाता है। अपने आप से निम्नलिखित प्रश्न पूछें: यदि UpdateAccountBalance परिवर्तन की आवश्यकताएं हैं, तो क्या यह UpdateAllAccountBalances को बिल्कुल उसी तरह प्रभावित करेगा? यदि उत्तर हाँ है, तो इसे प्राप्त करने का सबसे अच्छा तरीका UpdateAllAccountBalancesUpdateAccountBalance पर कॉल करना है, अन्यथा, आपको लगातार बनाए रखने के लिए आपको दो स्थानों में बदलाव करने की आवश्यकता होगी। यदि उत्तर नहीं है, तो आप दो इंटरैक्शन को रद्द करना चाहते हैं, और यह उन्हें साझा किए गए कार्यों को कॉल करके किया जा सकता है।

Answer 2

मेरा सुझाव अलग-अलग समस्या से संपर्क करना है। प्रक्रियात्मक दृष्टिकोण का उपयोग करने के बजाय समस्या को डोमेन मॉडल में स्वयं का प्रतिनिधित्व करें। आप उपयोग मामलों के साथ कुछ समस्याओं को देखते हुए, जिनमें से एक यह है कि उनकी ग्रैन्युलरिटी आमतौर पर अनिश्चित है।

एक डोमेन मॉडल में, एक विशिष्ट चीज़ (यानी "खाता") का प्रतिनिधित्व करने का मानक तरीका दो ऑब्जेक्ट्स के साथ है।एक विशिष्ट खाते का प्रतिनिधित्व करता है, और एक संबंधित वस्तु उन सभी चीजों का प्रतिनिधित्व करती है जो सभी खातों के लिए आम हैं।

AccountCatalog (1) ---- (*) SpecificAccount 

आपके उदाहरण में, विशिष्ट खाता में एक सेवा (विधि) "अपडेटबैलेंस" होगी। खातासूची में एक सेवा (विधि) "UpdateAllBalances" है, जो अपने संग्रह में सभी विशिष्ट खातों को अद्यतन अद्यतन भेजता है।

अब कुछ भी अपडेटअॉलबैलेंस संदेश भेज सकता है। एक और वस्तु, मानव बातचीत, या एक और प्रणाली।

मुझे ध्यान रखना चाहिए कि यह अपडेट करने के बजाए किसी खाते को "जानना" (यानी बनाए रखना) अपनी शेष राशि के लिए आम हो सकता है।