सॉफ्टवेयर विकास में लड़ाई की जटिलता

यह किस बारे में है

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

समस्याओं का हम सामना करते हैं

सॉफ़्टवेयर विकसित करते समय हम रास्ते में बहुत सी कठिनाइयों का सामना करते हैं: अस्पष्ट आवश्यकताएं, गलत संचार, खराब विकास प्रक्रिया और इतने पर।

हम कुछ तकनीकी कठिनाइयों का भी सामना करते हैं: विरासत कोड हमें धीमा कर देता है, स्केलिंग मुश्किल है, अतीत के कुछ बुरे फैसले आज हमें दांतों में मारते हैं।

उनमें से सभी को समाप्त नहीं किया जा सकता है तो काफी कम हो सकता है, लेकिन एक मौलिक समस्या है जिसके बारे में आप कुछ नहीं कर सकते हैं: आपके सिस्टम की जटिलता।

आपके द्वारा विकसित की जा रही प्रणाली का विचार हमेशा जटिल होता है, चाहे आप इसे समझें या नहीं।
यहां तक ​​कि जब आप अभी तक एक और सीआरयूडी आवेदन कर रहे हैं, तो हमेशा कुछ किनारे मामले, कुछ मुश्किल चीजें होती हैं, और समय-समय पर कोई व्यक्ति पूछता है "अरे, क्या होगा अगर मैं इन परिस्थितियों में ऐसा करूं और यह करूं?" और आप कहते हैं, "हम्म, यह एक बहुत अच्छा सवाल है।"

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

लेकिन आइए उदार बनें और मान लें कि डोमेन विशेषज्ञों और व्यापार विश्लेषकों की यह टीम स्पष्ट रूप से संचार करती है और ठीक संगत आवश्यकताओं का उत्पादन करती है।

अब हमें अपने कोड में उस जटिल विचार को व्यक्त करने के लिए, उन्हें लागू करना होगा। अब वह कोड एक अन्य प्रणाली है, मूल विचार की तुलना में अधिक जटिल है जो हमारे मन में था।

ऐसा कैसे? यह वास्तविकता का सामना करता है: तकनीकी सीमाएं आपको वास्तविक व्यवसाय तर्क को लागू करने के शीर्ष पर उच्च भार, डेटा स्थिरता और उपलब्धता से निपटने के लिए मजबूर करती हैं।

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

तकनीकी पहलू

अधिकांश लोकप्रिय भाषाएँ आज एक वस्तु उन्मुख हैं। जब कोई OOP से परिचय करता है तो वे आमतौर पर उदाहरणों का उपयोग करते हैं:
एक कार पर विचार करें, जो वास्तविक दुनिया से एक वस्तु है। इसमें ब्रांड, वजन, रंग, अधिकतम गति, वर्तमान गति और इसी तरह के विभिन्न गुण हैं।

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

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

बात यह है कि जब आप इन दिनों के एक विशिष्ट वेब अनुप्रयोग को देखते हैं, तो यह वस्तुओं के साथ व्यवहार नहीं करता है। हमारे कोड में लगभग हर चीज में या तो शाश्वत जीवनकाल है या कोई उचित जीवनकाल नहीं है। "ऑब्जेक्ट्स" के दो सबसे आम प्रकार कुछ प्रकार की सेवाएं हैं जैसे कि UserService , EmployeeRepository या कुछ मॉडल / संस्थाएं / डीटीओ या जो भी आप उन्हें कॉल करते हैं। सेवाओं के अंदर कोई तार्किक स्थिति नहीं है, वे मर जाते हैं और फिर से उसी के समान पैदा होते हैं, हम सिर्फ एक नए डेटाबेस कनेक्शन के साथ निर्भरता ग्राफ को फिर से बनाते हैं।

संस्थाओं और मॉडलों के पास कोई भी व्यवहार नहीं है, वे केवल डेटा के बंडल हैं, उनकी उत्परिवर्तन मदद नहीं करता है लेकिन काफी विपरीत है।

इसलिए OOP की प्रमुख विशेषताएं इस तरह के अनुप्रयोगों को विकसित करने के लिए वास्तव में उपयोगी नहीं हैं।

एक विशिष्ट वेब ऐप में क्या होता है डेटा प्रवाहित होता है: सत्यापन, परिवर्तन, मूल्यांकन और इसी तरह। और एक प्रतिमान है जो उस तरह की नौकरी के लिए पूरी तरह से फिट बैठता है: कार्यात्मक प्रोग्रामिंग। और इसके लिए एक सबूत है: लोकप्रिय भाषाओं में सभी आधुनिक विशेषताएं आज वहां से आती हैं: async/await , लैम्ब्डा और प्रतिनिधियों, प्रतिक्रियाशील प्रोग्रामिंग, भेदभाव रहित यूनियनों (स्विफ्ट या जंग में enums, java या .net में enums से भ्रमित होने के लिए नहीं)। ), ट्यूपल्स - वह सब जो एफपी से है।

हालाँकि, वे सिर्फ crumbles हैं, यह उनके लिए बहुत अच्छा है, लेकिन वहाँ अधिक है, जिस तरह से अधिक है।

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

उपकरण हमारे पास हैं और वे हमें क्या देते हैं

हम में से बहुत से लोग स्थैतिक टाइपिंग वाली भाषाएँ पसंद करते हैं। इसका कारण सरल है: कम्पाइलर कार्यों के लिए उचित मापदंडों को पारित करने, हमारी संस्थाओं को सही ढंग से और इसी तरह बनाने जैसे थकाऊ चेकों का ध्यान रखता है। ये चेक मुफ्त में आते हैं। अब, संकलक की जाँच नहीं कर सकने वाले सामान के लिए, हमारे पास एक विकल्प है: सर्वोत्तम के लिए आशा करें या कुछ परीक्षण करें। परीक्षण लिखने का अर्थ है पैसा, और आप परीक्षण के अनुसार सिर्फ एक बार भुगतान नहीं करते हैं, आपको उन्हें बनाए रखना होगा। इसके अलावा, लोग सुस्त हो जाते हैं, इसलिए हर बार एक समय में हमें झूठे सकारात्मक और झूठे नकारात्मक परिणाम मिलते हैं। आपको जितने अधिक परीक्षण लिखने हैं, उन परीक्षणों की औसत गुणवत्ता उतनी ही कम है। एक और समस्या है: किसी चीज़ का परीक्षण करने के लिए, आपको यह जानना और याद रखना होगा कि उस चीज़ का परीक्षण किया जाना चाहिए, लेकिन जितना बड़ा आपका सिस्टम उतना ही आसान होगा कि वह किसी चीज़ को याद कर सके।

हालाँकि संकलक केवल भाषा के प्रकार के रूप में अच्छा है। यदि यह आपको स्थैतिक तरीकों से कुछ व्यक्त करने की अनुमति नहीं देता है, तो आपको रनटाइम में ऐसा करना होगा। जिसका अर्थ है परीक्षण, हाँ। यह केवल प्रकार प्रणाली के बारे में नहीं है, हालांकि, सिंटैक्स और छोटी चीनी विशेषताएं बहुत महत्वपूर्ण हैं, क्योंकि दिन के अंत में हम जितना संभव हो उतना कम कोड लिखना चाहते हैं, इसलिए यदि कुछ दृष्टिकोण से आपको दस गुना अधिक लाइनें लिखने की आवश्यकता होती है, तो ठीक है, कोई भी इसका उपयोग करने वाला नहीं है। इसलिए यह महत्वपूर्ण है कि आपके द्वारा चुनी गई भाषा में सुविधाओं और ट्रिक्स का फिटिंग सेट हो - अच्छी तरह से, समग्र रूप से सही फोकस। यदि यह नहीं है - अपने सिस्टम की जटिलता और बदलती आवश्यकताओं जैसी मूल चुनौतियों से लड़ने के लिए इसकी सुविधाओं का उपयोग करने के बजाय, आप भाषा से भी लड़ने वाले हैं। और यह सब पैसे के लिए नीचे आता है, क्योंकि आप डेवलपर्स को उनके समय के लिए भुगतान करते हैं। उन्हें जितनी अधिक समस्या का समाधान करना होगा, उतने समय के लिए उन्हें जरूरत होगी और उतनी ही अधिक डेवलपर्स की जरूरत होगी।

अंत में हम सभी को साबित करने के लिए कुछ कोड देखने वाले हैं। मैं एक .NET डेवलपर होने जा रहा हूं, इसलिए कोड नमूने C # और F # में आने वाले हैं, लेकिन सामान्य चित्र कमोबेश अन्य लोकप्रिय OOP और FP भाषाओं में समान होंगे।

कोडिंग शुरू करते हैं

हम क्रेडिट कार्ड के प्रबंधन के लिए एक वेब एप्लिकेशन बनाने जा रहे हैं।

बुनियादी आवश्यकताएं:

• उपयोगकर्ता बनाएं / पढ़ें
• क्रेडिट कार्ड बनाएं / पढ़ें
• क्रेडिट कार्ड सक्रिय / निष्क्रिय करें
• कार्ड के लिए दैनिक सीमा निर्धारित करें
• टॉप अप बैलेंस
• प्रक्रिया भुगतान (शेष राशि, कार्ड समाप्ति की तारीख, सक्रिय / निष्क्रिय स्थिति और दैनिक सीमा पर विचार)

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

पहले, आइए देखें कि यह C # में कैसा दिखेगा

 public class Card { public string CardNumber {get;set;} public string Name {get;set;} public int ExpirationMonth {get;set;} public int ExpirationYear {get;set;} public bool IsActive {get;set;} public AccountInfo AccountInfo {get;set;} } public class AccountInfo { public decimal Balance {get;set;} public string CardNumber {get;set;} public decimal DailyLimit {get;set;} } 

लेकिन यह पर्याप्त नहीं है, हमें सत्यापन को जोड़ना होगा, और आमतौर पर यह कुछ Validator में किया जा रहा है, जैसे कि FluentValidation ।

नियम सरल हैं:

• कार्ड नंबर आवश्यक है और 16 अंकों का स्ट्रिंग होना चाहिए।
• नाम की आवश्यकता है और इसमें केवल अक्षर होने चाहिए और बीच में रिक्त स्थान हो सकते हैं।
• महीना और साल सीमाओं को संतुष्ट करना है।
• कार्ड के सक्रिय होने और कार्ड के निष्क्रिय होने पर खाता जानकारी मौजूद होनी चाहिए। यदि आप सोच रहे हैं कि क्यों, यह सरल है: जब कार्ड को निष्क्रिय कर दिया जाता है, तो शेष राशि या दैनिक सीमा को बदलना संभव नहीं होना चाहिए।

 public class CardValidator : IValidator { internal static CardNumberRegex = new Regex("^[0-9]{16}$"); internal static NameRegex = new Regex("^[\w]+[\w ]+[\w]+$"); public CardValidator() { RuleFor(x => x.CardNumber) .Must(c => !string.IsNullOrEmpty(c) && CardNumberRegex.IsMatch(c)) .WithMessage("oh my"); RuleFor(x => x.Name) .Must(c => !string.IsNullOrEmpty(c) && NameRegex.IsMatch(c)) .WithMessage("oh no"); RuleFor(x => x.ExpirationMonth) .Must(x => x >= 1 && x <= 12) .WithMessage("oh boy"); RuleFor(x => x.ExpirationYear) .Must(x => x >= 2019 && x <= 2023) .WithMessage("oh boy"); RuleFor(x => x.AccountInfo) .Null() .When(x => !x.IsActive) .WithMessage("oh boy"); RuleFor(x => x.AccountInfo) .NotNull() .When(x => x.IsActive) .WithMessage("oh boy"); } } 

अब इस दृष्टिकोण के साथ कई समस्याएं हैं:

• सत्यापन को प्रकार की घोषणा से अलग किया गया है, जिसका अर्थ है कि हमें वास्तव में किस कार्ड की पूरी तस्वीर देखनी है, कोड के माध्यम से नेविगेट करना होगा और हमारे सिर में इस छवि को फिर से बनाना होगा। यह एक बड़ी समस्या नहीं है जब यह केवल एक बार होता है, लेकिन जब हमें एक बड़ी परियोजना में हर एक इकाई के लिए ऐसा करना है, तो ठीक है, यह बहुत समय लेने वाला है।
• यह सत्यापन मजबूर नहीं है, हमें इसे हर जगह उपयोग करने के लिए ध्यान में रखना होगा। हम परीक्षणों के साथ इसे सुनिश्चित कर सकते हैं, लेकिन फिर, आपको परीक्षण लिखते समय इसके बारे में याद रखना होगा।
• जब हम कार्ड नंबर को अन्य स्थानों पर मान्य करना चाहते हैं, तो हमें फिर से वही काम करना होगा। ज़रूर, हम regex को एक सामान्य स्थान पर रख सकते हैं, लेकिन फिर भी हमें इसे हर सत्यापनकर्ता में कॉल करना होगा।

F # में हम इसे अलग तरीके से कर सकते हैं:

 (*{- First we define a type for CardNumber with private constructor and public factory which receives string and returns `Result<CardNumber, string>`. Normally we would use `ValidationError` instead, but string is good enough for example -}*) type CardNumber = private CardNumber of string with member this.Value = match this with CardNumber s -> s static member create str = match str with | (null|"") -> Error "card number can't be empty" | str -> if cardNumberRegex.IsMatch(str) then CardNumber str |> Ok else Error "Card number must be a 16 digits string" (*{- Then in here we express this logic "when card is deactivated, balance and daily limit manipulations aren't available". Note that this is way easier to grasp that reading `RuleFor()` in validators. -}*) type CardAccountInfo = | Active of AccountInfo | Deactivated (*{- And then that's it. The whole set of rules is here, and it's described in a static way. We don't need tests for that, the compiler is our test. And we can't accidentally miss this validation. -}*) type Card = { CardNumber: CardNumber Name: LetterString //-- LetterString is another type with built-in validation HolderId: UserId Expiration: (Month * Year) AccountDetails: CardAccountInfo } 

बेशक यहाँ से कुछ चीजें हम C # में कर सकते हैं। हम CardNumber क्लास बना सकते हैं जो CardNumber को वहां भी फेंक देगा। लेकिन CardAccountInfo साथ यह ट्रिक आसान तरीके से C # में नहीं किया जा सकता है।
एक और बात - सी # अपवादों पर भारी निर्भर करती है। इसके साथ कई समस्याएं हैं:

• अपवाद में "अर्थ" जाना जाता है। एक क्षण तुम इस विधि में यहां हो, दूसरा - तुम किसी वैश्विक हैंडलर में समाप्त हो गए।
• वे विधि हस्ताक्षर में दिखाई नहीं देते हैं। ValidationException या InvalidUserOperationException जैसे अपवाद अनुबंध का हिस्सा हैं, लेकिन आप यह नहीं जानते कि जब तक आप इसे लागू नहीं करते हैं। और यह एक बड़ी समस्या है, क्योंकि काफी बार आपको किसी और द्वारा लिखे गए कोड का उपयोग करना पड़ता है, और केवल हस्ताक्षर को पढ़ने के बजाय, आपको कॉल स्टैक के निचले भाग में सभी तरह से नेविगेट करना होगा, जिसमें बहुत समय लगता है।

और यह मुझे परेशान करता है: जब भी मैं किसी नई सुविधा को लागू करता हूं, तो कार्यान्वयन प्रक्रिया में अधिक समय नहीं लगता है, इसका अधिकांश भाग दो चरणों में जाता है:

• अन्य लोगों के कोड को पढ़ना और व्यावसायिक तर्क नियमों का पता लगाना।
• सुनिश्चित करें कि कुछ भी टूटा हुआ नहीं है।

यह एक खराब कोड डिज़ाइन के लक्षण की तरह लग सकता है, लेकिन यही बात शालीनता से लिखे गए प्रोजेक्टों पर भी होती है।
ठीक है, लेकिन हम C # में समान Result उपयोग करने का प्रयास कर सकते हैं। सबसे स्पष्ट कार्यान्वयन इस तरह दिखेगा:

 public class Result<TOk, TError> { public TOk Ok {get;set;} public TError Error {get;set;} } 

और यह एक शुद्ध कचरा है, यह हमें Ok और Error दोनों को सेट करने से नहीं रोकता है और त्रुटि को पूरी तरह से नजरअंदाज करने की अनुमति देता है। उचित संस्करण कुछ इस तरह होगा:

 public abstract class Result<TOk, TError> { public abstract bool IsOk { get; } private sealed class OkResult : Result<TOk, TError> { public readonly TOk _ok; public OkResult(TOk ok) { _ok = ok; } public override bool IsOk => true; } private sealed class ErrorResult : Result<TOk, TError> { public readonly TError _error; public ErrorResult(TError error) { _error = error; } public override bool IsOk => false; } public static Result<TOk, TError> Ok(TOk ok) => new OkResult(ok); public static Result<TOk, TError> Error(TError error) => new ErrorResult(error); public Result<T, TError> Map<T>(Func<TOk, T> map) { if (this.IsOk) { var value = ((OkResult)this)._ok; return Result<T, TError>.Ok(map(value)); } else { var value = ((ErrorResult)this)._error; return Result<T, TError>.Error(value); } } public Result<TOk, T> MapError<T>(Func<TError, T> mapError) { if (this.IsOk) { var value = ((OkResult)this)._ok; return Result<TOk, T>.Ok(value); } else { var value = ((ErrorResult)this)._error; return Result<TOk, T>.Error(mapError(value)); } } } 

बहुत बोझिल, सही? और मैंने Map और MapError के void संस्करणों को भी लागू नहीं किया। उपयोग इस तरह दिखेगा:

 void Test(Result<int, string> result) { var squareResult = result.Map(x => x * x); } 

इतना बुरा नहीं है, उह? ठीक है, अब आप कल्पना करें कि आपके तीन परिणाम हैं और आप उन सभी के साथ कुछ करना चाहते हैं, जब सभी Ok । बुरा। तो वह शायद ही कोई विकल्प हो।
एफ # संस्करण:

 //-- this type is in standard library, but declaration looks like this: type Result<'ok, 'error> = | Ok of 'ok | Error of 'error //-- and usage: let test res1 res2 res3 = match res1, res2, res3 with | Ok ok1, Ok ok2, Ok ok3 -> printfn "1: %A 2: %A 3: %A" ok1 ok2 ok3 | _ -> printfn "fail" 

मूल रूप से, आपको यह चुनना होगा कि आप उचित मात्रा में कोड लिखते हैं, लेकिन कोड अस्पष्ट है, अपवादों, प्रतिबिंब, अभिव्यक्तियों और अन्य "जादू" पर निर्भर करता है, या आप बहुत अधिक कोड लिखते हैं, जो पढ़ना मुश्किल है, लेकिन यह अधिक टिकाऊ है और सीधे आगे। जब इस तरह की परियोजना बड़ी हो जाती है तो आप इसका मुकाबला नहीं कर सकते हैं, न कि सी # जैसी टाइप प्रणालियों वाले भाषाओं में। आइए एक साधारण परिदृश्य पर विचार करें: आपके पास कोडबसे में थोड़ी देर के लिए कुछ इकाई है। आज आप एक नया आवश्यक क्षेत्र जोड़ना चाहते हैं। स्वाभाविक रूप से आपको इस फ़ील्ड को हर जगह इनिशियलाइज़ करने की आवश्यकता होती है, लेकिन यह कंपाइलर आपकी मदद नहीं करता है, क्योंकि क्लास म्यूटेबल है और null एक वैल्यू वैल्यू है। और AutoMapper जैसी लाइब्रेरी इसे और भी कठिन बनाती हैं। यह परिवर्तनशीलता हमें वस्तुओं को एक स्थान पर आंशिक रूप से आरंभ करने की अनुमति देती है, फिर इसे कहीं और धकेलती है और वहां आरंभीकरण जारी रखती है। यह कीड़े का एक और स्रोत है।

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

ताकि हमें इन सवालों से रुबरु कराया जाए:

1. हमें वास्तव में आधुनिक ओओपी से स्विच करने की आवश्यकता क्यों है?
2. हमें एफपी पर स्विच क्यों करना चाहिए?

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

और दूसरा जवाब है एफपी भाषाएँ आपको अपनी सुविधाओं को डिज़ाइन करने का एक आसान तरीका देती हैं ताकि वे घड़ी की तरह काम करें, और यदि कोई नया फीचर मौजूदा तर्क को तोड़ता है, तो यह कोड को तोड़ देता है, इसलिए आपको तुरंत पता चल जाता है।

हालाँकि वे उत्तर पर्याप्त नहीं हैं। जैसा कि मेरे मित्र ने हमारी चर्चाओं में से एक के दौरान बताया, एफपी पर स्विच करना तब बेकार होगा जब आप सर्वोत्तम प्रथाओं को नहीं जानते हैं। हमारे बड़े उद्योग ने ओओपी अनुप्रयोगों के डिजाइन के बारे में लेखों, पुस्तकों और ट्यूटोरियल के टन का उत्पादन किया, और हमारे पास ओओपी के साथ उत्पादन का अनुभव है, इसलिए हम जानते हैं कि विभिन्न दृष्टिकोणों से क्या उम्मीद है। दुर्भाग्य से, यह कार्यात्मक प्रोग्रामिंग के लिए मामला नहीं है, इसलिए यहां तक ​​कि अगर आप एफपी पर स्विच करते हैं, तो आपका पहला प्रयास सबसे अजीब होगा और निश्चित रूप से आपको वांछित परिणाम नहीं लाएगा: जटिल सिस्टम का तेज और दर्द रहित विकास।

खैर, यह ठीक है कि यह लेख किस बारे में है। जैसा कि मैंने कहा, हम अंतर देखने के लिए प्रोडक्शन जैसे एप्लिकेशन का निर्माण करने जा रहे हैं।

हम आवेदन कैसे डिजाइन करते हैं?

इस तरह के बहुत सारे विचार जो मैंने डिजाइन की प्रक्रिया में उपयोग किए थे, मैंने महान पुस्तक डोमेन मॉडलिंग मेड फंक्शनल से उधार लिया था, इसलिए मैं आपको इसे पढ़ने के लिए दृढ़ता से प्रोत्साहित करता हूं।

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

हमारे पास 4 मुख्य परियोजनाएँ होंगी: व्यावसायिक परत, डेटा एक्सेस परत, बुनियादी ढांचा और, ज़ाहिर है, आम। हर समाधान है, है ना?

हम अपने डोमेन की मॉडलिंग से शुरुआत करते हैं। इस बिंदु पर हम नहीं जानते हैं और डेटाबेस की परवाह नहीं करते हैं। यह उद्देश्य पर किया गया है, क्योंकि विशिष्ट डेटाबेस को ध्यान में रखते हुए हम अपने डोमेन को इसके अनुसार डिज़ाइन करते हैं, हम इस इकाई-तालिका संबंध को व्यावसायिक परत में लाते हैं, जो बाद में समस्याएं लाता है। आपको केवल मैपिंग domain -> DAL लागू करने की आवश्यकता है domain -> DAL एक बार, जबकि गलत डिज़ाइन हमें लगातार परेशान करेगा जब तक कि हम इसे ठीक नहीं कर लेते। तो यहाँ हम क्या करते हैं: हम CardManagement (बहुत रचनात्मक, मुझे पता है) नामक एक प्रोजेक्ट बनाते हैं, और तुरंत प्रोजेक्ट फ़ाइल में <TreatWarningsAsErrors>true</TreatWarningsAsErrors> सेटिंग चालू करते हैं। हमें इसकी आवश्यकता क्यों है? ठीक है, हम विवेकहीन संघों का भारी उपयोग करने जा रहे हैं, और जब आप पैटर्न मिलान करते हैं, तो कंपाइलर हमें एक चेतावनी देता है, अगर हम सभी संभावित मामलों को कवर नहीं करते हैं:

 let fail result = match result with | Ok v -> printfn "%A" v //-- warning: Incomplete pattern matches on this expression. //-- For example, the value 'Error' may indicate a case not covered by the pattern(s). 

इस सेटिंग के साथ, यह कोड अभी संकलित नहीं होगा, जो कि वास्तव में हमारी जरूरत है, जब हम मौजूदा कार्यक्षमता का विस्तार करते हैं और चाहते हैं कि इसे हर जगह समायोजित किया जाए। अगली चीज जो हम करते हैं वह है मॉड्यूल बनाना (यह एक स्थिर वर्ग में संकलित करता है) CardDomain । इस फ़ाइल में हम डोमेन प्रकारों का वर्णन करते हैं और इससे अधिक कुछ नहीं। ध्यान रखें कि एफ # में, कोड और फाइल ऑर्डर के मामले: डिफ़ॉल्ट रूप से आप केवल वही उपयोग कर सकते हैं जो आपने पहले घोषित किया था।

डोमेन प्रकार

हम CardNumber साथ हमारे प्रकारों को परिभाषित करना शुरू करते हैं, CardNumber मैंने पहले दिखाया था, हालांकि हमें बस एक स्ट्रिंग की तुलना में अधिक व्यावहारिक Error आवश्यकता है, इसलिए हम ValidationError उपयोग करेंगे।

 type ValidationError = { FieldPath: string Message: string } let validationError field message = { FieldPath = field; Message = message } (*{- Actually we should use here Luhn's algorithm, but I leave it to you as an exercise, so you can see for yourself how easy is updating code to new requirements. -}*) let private cardNumberRegex = new Regex("^[0-9]{16}$", RegexOptions.Compiled) type CardNumber = private CardNumber of string with member this.Value = match this with CardNumber s -> s static member create fieldName str = match str with | (null|"") -> validationError fieldName "card number can't be empty" | str -> if cardNumberRegex.IsMatch(str) then CardNumber str |> Ok else validationError fieldName "Card number must be a 16 digits string" 

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

 type AccountInfo = { HolderId: UserId Balance: Money DailyLimit: DailyLimit } type Card = { CardNumber: CardNumber Name: LetterString HolderId: UserId Expiration: (Month * Year) AccountDetails: CardAccountInfo } 

अब, यहाँ कई प्रकार हैं, जिन्हें हमने अभी तक घोषित नहीं किया है:

1. पैसा

   
   

   हम decimal उपयोग कर सकते हैं (और हम करेंगे, लेकिन सीधे नहीं), लेकिन decimal कम वर्णनात्मक है। इसके अलावा, यह पैसे के अलावा अन्य चीजों के प्रतिनिधित्व के लिए इस्तेमाल किया जा सकता है, और हम इसे मिश्रित नहीं करना चाहते हैं। इसलिए हम कस्टम प्रकार के type [<Struct>] Money = Money of decimal उपयोग करते हैं type [<Struct>] Money = Money of decimal ।

   
   

2. DailyLimit

   
   

   दैनिक सीमा या तो एक विशिष्ट राशि पर सेट की जा सकती है या बिल्कुल अनुपस्थित हो सकती है। यदि यह मौजूद है, तो यह सकारात्मक होना चाहिए। decimal या Money का उपयोग करने के बजाय हम इस प्रकार को परिभाषित करते हैं:

   
   

    [<Struct>] type DailyLimit = private //-- private constructor so it can't be created directly outside of module | Limit of Money | Unlimited with static member ofDecimal dec = if dec > 0m then Money dec |> Limit else Unlimited member this.ToDecimalOption() = match this with | Unlimited -> None | Limit limit -> Some limit.Value 

   
   

   यह केवल विवरण देने से अधिक वर्णनात्मक है कि 0M मतलब है कि इसकी कोई सीमा नहीं है, क्योंकि इसका मतलब यह भी हो सकता है कि आप इस कार्ड पर पैसा खर्च नहीं कर सकते। एकमात्र समस्या यह है कि हमने कंस्ट्रक्टर को छिपा दिया है, हम पैटर्न मिलान नहीं कर सकते। लेकिन कोई चिंता नहीं, हम सक्रिय पैटर्न का उपयोग कर सकते हैं:

   
   

    let (|Limit|Unlimited|) limit = match limit with | Limit dec -> Limit dec | Unlimited -> Unlimited 

   
   

   अब हम DailyLimit हर जगह रेगुलर डीयू के रूप में मैच कर सकते हैं।

   
   

3. LetterString

   
   

   वह सरल है। हम CardNumber में उसी तकनीक का उपयोग करते हैं। हालांकि एक छोटी सी बात: LetterString क्रेडिट कार्ड के बारे में शायद ही हो, यह एक अच्छी बात है और हमें इसे CommonTypes मॉड्यूल में Common प्रोजेक्ट में स्थानांतरित करना चाहिए। समय आता है हम ValidationError को अलग जगह पर स्थानांतरित करते हैं।

   
   

4. प्रयोक्ता-आईडी

   
   

   वह केवल एक उपनाम type UserId = System.Guid । हम इसे केवल वर्णनात्मकता के लिए उपयोग करते हैं।

   
   

5. महीना और साल

   
   

   जिन्हें Common भी जाना है। Month को भेदभाव रहित संघ बनाने के लिए है और इसे unsigned int16 से बदलने के लिए, Year CardNumber तरह होने जा रहा है लेकिन स्ट्रिंग के बजाय uint16 लिए।

   
   

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

  type UserInfo = { Name: LetterString Id: UserId Address: Address } type User = { UserInfo : UserInfo Cards: Card list } [<Struct>] type BalanceChange = //-- another common type with validation for positive amount | Increase of increase: MoneyTransaction | Decrease of decrease: MoneyTransaction with member this.ToDecimal() = match this with | Increase i -> i.Value | Decrease d -> -d.Value [<Struct>] type BalanceOperation = { CardNumber: CardNumber Timestamp: DateTimeOffset BalanceChange: BalanceChange NewBalance: Money } 

अच्छा है, हमने अपने प्रकारों को इस तरह से डिज़ाइन किया है कि अमान्य राज्य अप्राप्य है। अब जब भी हम इनमें से किसी भी प्रकार के उदाहरण के साथ सौदा करते हैं तो हमें यकीन है कि वहाँ डेटा मान्य है और हमें इसे फिर से मान्य नहीं करना है। अब हम व्यापार तर्क के लिए आगे बढ़ सकते हैं!

व्यापार तर्क

हमारे यहाँ एक अटूट नियम होगा: सभी व्यावसायिक तर्क को शुद्ध कार्यों में कूटबद्ध किया जाएगा। शुद्ध कार्य एक ऐसा कार्य है जो निम्न मानदंडों को पूरा करता है:

• केवल एक चीज जो आउटपुट मूल्य की गणना करती है। इसका कोई साइड इफेक्ट बिल्कुल नहीं है।
• यह हमेशा एक ही इनपुट के लिए एक ही आउटपुट का उत्पादन करता है।

इसलिए शुद्ध कार्य अपवादों को नहीं फेंकते हैं, यादृच्छिक मूल्यों का उत्पादन नहीं करते हैं, किसी भी रूप में बाहरी दुनिया के साथ बातचीत नहीं करते हैं, यह डेटाबेस या एक सरल DateTime.Now । अब कैसे। बेशक अशुद्ध समारोह के साथ बातचीत स्वचालित रूप से फ़ंक्शन अशुद्ध को प्रस्तुत करता है। तो हम क्या लागू करेंगे?

यहां हमारे पास आवश्यकताओं की एक सूची है:

• कार्ड को सक्रिय / निष्क्रिय करें

  
  

• प्रक्रिया भुगतान

  
  

  हम भुगतान की प्रक्रिया कर सकते हैं यदि:

  
  
  1. कार्ड की समय सीमा समाप्त नहीं हुई है
  2. कार्ड सक्रिय है
  3. भुगतान के लिए पर्याप्त धन है
  4. आज के लिए व्यय दैनिक सीमा से अधिक नहीं है।
  
  

• टॉप अप बैलेंस

  
  

  हम सक्रिय और एक्सपायर्ड कार्ड के लिए बैलेंस नहीं बना सकते हैं।

  
  

• दैनिक सीमा निर्धारित करें

  
  

  यदि कार्ड की समय सीमा समाप्त नहीं हुई है और सक्रिय है, तो उपयोगकर्ता दैनिक सीमा निर्धारित कर सकता है।

  
  

जब ऑपरेशन पूरा नहीं हो सकता है, तो हमें एक त्रुटि वापस करनी होगी, इसलिए हमें ऑपरेशननोटअलगार्डर को परिभाषित करने की आवश्यकता है:

  type OperationNotAllowedError = { Operation: string Reason: string } //-- and a helper function to wrap it in `Error` which is a case for `Result<'ok,'error> type let operationNotAllowed operation reason = { Operation = operation; Reason = reason } |> Error 

व्यापार तर्क के साथ इस मॉड्यूल में एक ही प्रकार की त्रुटि होगी जो हम वापस करते हैं। हम यहां सत्यापन नहीं करते हैं, डेटाबेस के साथ बातचीत नहीं करते हैं - बस संचालन को निष्पादित कर रहे हैं यदि हम अन्यथा ऑपरेशननोटअलाइगडवर्ड वापस कर सकते हैं।

पूर्ण मॉड्यूल यहां पाया जा सकता है । मैं यहाँ पेचीदा मामला यहाँ सूचीबद्ध करूँगा: processPayment । हमें समाप्ति, सक्रिय / निष्क्रिय स्थिति, आज खर्च किए गए धन और वर्तमान शेष के लिए जांच करनी होगी। चूंकि हम बाहरी दुनिया के साथ बातचीत नहीं कर सकते हैं, इसलिए हमें सभी आवश्यक जानकारी को मापदंडों के रूप में पारित करना होगा। इस तरह इस तर्क का परीक्षण करना बहुत आसान होगा, और आपको संपत्ति आधारित परीक्षण करने की अनुमति मिलती है।

 let processPayment (currentDate: DateTimeOffset) (spentToday: Money) card (paymentAmount: MoneyTransaction) = //-- first check for expiration if isCardExpired currentDate card then cardExpiredMessage card.CardNumber |> processPaymentNotAllowed else //-- then active/deactivated match card.AccountDetails with | Deactivated -> cardDeactivatedMessage card.CardNumber |> processPaymentNotAllowed | Active accInfo -> //-- if active then check balance if paymentAmount.Value > accInfo.Balance.Value then sprintf "Insufficent funds on card %s" card.CardNumber.Value |> processPaymentNotAllowed else //-- if balance is ok check limit and money spent today match accInfo.DailyLimit with | Limit limit when limit < spentToday + paymentAmount -> sprintf "Daily limit is exceeded for card %s with daily limit %M. Today was spent %M" card.CardNumber.Value limit.Value spentToday.Value |> processPaymentNotAllowed (*{- We could use here the ultimate wild card case like this: | _ -> but it's dangerous because if a new case appears in `DailyLimit` type, we won't get a compile error here, which would remind us to process this new case in here. So this is a safe way to do the same thing. -}*) | Limit _ | Unlimited -> let newBalance = accInfo.Balance - paymentAmount let updatedCard = { card with AccountDetails = Active { accInfo with Balance = newBalance } } //-- note that we have to return balance operation, //-- so it can be stored to DB later. let balanceOperation = { Timestamp = currentDate CardNumber = card.CardNumber NewBalance = newBalance BalanceChange = Decrease paymentAmount } Ok (updatedCard, balanceOperation) 

यह spentToday - हमें इसे डेटाबेस में रखे BalanceOperation संग्रह से गणना करना होगा। तो हमें इसके लिए मॉड्यूल की आवश्यकता होगी, जिसमें मूल रूप से 1 सार्वजनिक फ़ंक्शन होगा:

  let private isDecrease change = match change with | Increase _ -> false | Decrease _ -> true let spentAtDate (date: DateTimeOffset) cardNumber operations = let date = date.Date let operationFilter { CardNumber = number; BalanceChange = change; Timestamp = timestamp } = isDecrease change && number = cardNumber && timestamp.Date = date let spendings = List.filter operationFilter operations List.sumBy (fun s -> -s.BalanceChange.ToDecimal()) spendings |> Money 

अच्छा। अब जब हम मानचित्रण के बारे में सोचने के लिए सभी व्यावसायिक तर्क कार्यान्वयन, समय के साथ कर रहे हैं। हमारे बहुत से प्रकार भेदभावपूर्ण संघों का उपयोग करते हैं, हमारे कुछ प्रकारों का कोई सार्वजनिक निर्माणकर्ता नहीं है, इसलिए हम उन्हें बाहर की दुनिया के समान उजागर नहीं कर सकते। हमें (डी) क्रमांकन से निपटना होगा। इसके अलावा, अभी हमारे पास हमारे आवेदन में केवल एक बाध्य संदर्भ है, लेकिन बाद में वास्तविक जीवन में आप कई बंधे हुए संदर्भों के साथ एक बड़ी प्रणाली का निर्माण करना चाहते हैं, और उन्हें सार्वजनिक अनुबंधों के माध्यम से एक-दूसरे के साथ बातचीत करनी होगी, जो कि समझ से बाहर होना चाहिए अन्य प्रोग्रामिंग भाषाओं सहित सभी के लिए।

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

यहाँ यह कैसा दिखता है:

 (*{- You can use type aliases to annotate your functions. This is just an example, but sometimes it makes code more readable -}*) type ValidateCreateCardCommand = CreateCardCommandModel -> ValidationResult<Card> let validateCreateCardCommand : ValidateCreateCardCommand = fun cmd -> (*{- that's a computation expression for `Result<>` type. Thanks to this we don't have to chose between short code and strait forward one, like we have to do in C# -}*) result { let! name = LetterString.create "name" cmd.Name let! number = CardNumber.create "cardNumber" cmd.CardNumber let! month = Month.create "expirationMonth" cmd.ExpirationMonth let! year = Year.create "expirationYear" cmd.ExpirationYear return { Card.CardNumber = number Name = name HolderId = cmd.UserId Expiration = month,year AccountDetails = AccountInfo.Default cmd.UserId |> Active } } 

मैपिंग और मान्यता के लिए पूर्ण मॉड्यूल यहां है और मॉडल के मानचित्रण के लिए मॉड्यूल यहां है ।

इस बिंदु पर हमारे पास सभी व्यापारिक तर्क, मैपिंग, सत्यापन और इतने पर कार्यान्वयन है, और अब तक यह सब वास्तविक दुनिया से पूरी तरह से अलग है: यह पूरी तरह से शुद्ध कार्यों में लिखा गया है। अब आप शायद सोच रहे होंगे कि हम वास्तव में इसका उपयोग कैसे करेंगे? क्योंकि हमें बाहरी दुनिया से बातचीत करनी होगी। इससे अधिक, वर्कफ़्लो निष्पादन के दौरान हमें उन वास्तविक-विश्व इंटरैक्शन के परिणाम के आधार पर कुछ निर्णय लेने होंगे। तो सवाल यह है कि हम इस सब को कैसे इकट्ठा करते हैं? OOP में वे आईओसी कंटेनरों का उपयोग करते हैं, लेकिन इसकी देखभाल के लिए हम यहाँ ऐसा नहीं कर सकते हैं, क्योंकि हमारे पास वस्तुएं नहीं हैं, हमारे पास स्थिर कार्य हैं।

हम उस के लिए Interpreter pattern उपयोग करने वाले हैं! यह थोड़ा मुश्किल है, ज्यादातर इसलिए कि यह अपरिचित है, लेकिन मैं इस पैटर्न को समझाने की पूरी कोशिश करूंगा। सबसे पहले, फ़ंक्शन रचना के बारे में बात करते हैं। उदाहरण के लिए हमारे पास एक फंक्शन int -> string । इसका मतलब है कि फ़ंक्शन एक पैरामीटर के रूप में int अपेक्षा करता है और स्ट्रिंग लौटाता है। अब हम कहते हैं कि हमारे पास एक और फ़ंक्शन string -> char । इस बिंदु पर हम उन्हें चेन कर सकते हैं, यानी पहले एक को निष्पादित करें, इसे आउटपुट लें और इसे दूसरे फ़ंक्शन पर फ़ीड करें, और इसके लिए एक ऑपरेटर भी है: >> यहां बताया गया है कि यह कैसे काम करता है:

 let intToString (i: int) = i.ToString() let firstCharOrSpace (s: string) = match s with | (null| "") -> ' ' | s -> s.[0] let firstDigitAsChar = intToString >> firstCharOrSpace //-- And you can chain as many functions as you like let alwaysTrue = intToString >> firstCharOrSpace >> Char.IsDigit 

हालाँकि हम कुछ परिदृश्यों में साधारण चैनिंग का उपयोग नहीं कर सकते हैं, जैसे कि कार्ड को सक्रिय करना। यहाँ क्रियाओं का क्रम है:

• इनपुट कार्ड नंबर मान्य करें। यदि यह मान्य है, तो
• इस संख्या द्वारा कार्ड प्राप्त करने का प्रयास करें। अगर एक है
• इसे सक्रिय करें।
• परिणाम सहेजें। अगर ठीक है तो
• मॉडल के लिए नक्शा और वापसी।

पहले दो चरणों में यह है कि If it's ok then... यही वजह है कि डायरेक्ट चेनिंग काम नहीं कर रही है।

हम बस उन कार्यों को पैरामीटर के रूप में इंजेक्ट कर सकते हैं, जैसे:

 let activateCard getCardAsync saveCardAsync cardNumber = ... 

लेकिन उस के साथ कुछ समस्याएं हैं। सबसे पहले, निर्भरता की संख्या बड़ी हो सकती है और फ़ंक्शन हस्ताक्षर बदसूरत दिखेंगे। दूसरा, हम यहां विशिष्ट प्रभावों से बंधे हैं: हमें यह चुनना है कि क्या यह एक Task या Async या सिर्फ सादा सिंक कॉल। तीसरा, जब आप पास करने के लिए कई कार्य करते हैं, तो चीजों को createUserAsync : उदाहरण के लिए createUserAsync और replaceUserAsync पर एक ही हस्ताक्षर होते हैं, लेकिन अलग-अलग प्रभाव होते हैं, इसलिए जब आपको उन्हें सैकड़ों बार पास करना पड़ता है तो आप वास्तव में अजीब लक्षणों के साथ गलती कर सकते हैं। उन कारणों के कारण हम दुभाषिया के लिए जाते हैं।

विचार यह है कि हम अपने कंपोजिशन कोड को 2 भागों में विभाजित करते हैं: निष्पादन ट्री और उस पेड़ के लिए दुभाषिया। इस पेड़ में प्रत्येक नोड एक फ़ंक्शन के लिए एक जगह है जिसके प्रभाव को हम इंजेक्ट करना चाहते हैं, जैसे getUserFromDatabase । उन नोड्स को नाम से परिभाषित किया जाता है, जैसे getCard , इनपुट पैरामीटर प्रकार, जैसे CardNumber और रिटर्न प्रकार, जैसे Card option । हम यहां Task या Async निर्दिष्ट नहीं करते हैं, यह पेड़ का हिस्सा नहीं है, यह दुभाषिया का एक हिस्सा है । इस पेड़ का हर किनारा शुद्ध परिवर्तन की कुछ श्रृंखला है, जैसे सत्यापन या व्यवसाय तर्क फ़ंक्शन निष्पादन। किनारों में कुछ इनपुट भी होते हैं, जैसे कच्चे स्ट्रिंग कार्ड नंबर, फिर सत्यापन होता है, जो हमें एक त्रुटि या वैध कार्ड नंबर दे सकता है। यदि कोई त्रुटि है, तो हम उस किनारे को बाधित करने वाले हैं, यदि नहीं, तो यह हमें अगले नोड तक ले जाता है: getCard । यदि यह नोड Some card लौटाएगा, तो हम अगले किनारे पर जारी रख सकते हैं, जो सक्रिय होगा, और इसी तरह।

topUp या topUp या topUp जैसे हर परिदृश्य के लिए हम एक अलग पेड़ बनाने जा रहे हैं। जब उन पेड़ों को बनाया जाता है, तो उनके नोड थोड़े खाली होते हैं, उनमें वास्तविक कार्य नहीं होते हैं, उन कार्यों के लिए एक जगह होती है। दुभाषिया का लक्ष्य उन नोड्स को भरना है, जो सरल है। दुभाषिया हमारे द्वारा उपयोग किए जाने वाले प्रभावों को जानता है, जैसे Task , और यह जानता है कि किसी दिए गए नोड में कौन सा वास्तविक कार्य करना है। जब यह एक नोड का दौरा करता है, तो यह संबंधित वास्तविक फ़ंक्शन को निष्पादित करता है, इसे Task या Async मामले में इंतजार करता है, और परिणाम को अगले किनारे पर भेजता है। यह बढ़त दूसरे नोड को जन्म दे सकती है, और फिर यह दुभाषिया के लिए फिर से एक काम है, जब तक कि यह दुभाषिया स्टॉप नोड तक नहीं पहुंचता है, हमारी पुनरावृत्ति के नीचे, जहां हम सिर्फ हमारे पेड़ के पूरे निष्पादन का परिणाम देते हैं।

पूरे पेड़ को भेदभाव वाले संघ के साथ प्रतिनिधित्व किया जाएगा, और एक नोड इस तरह दिखेगा:

  type Program<'a> = | GetCard of CardNumber * (Card option -> Program<'a>) //-- <- THE NODE | ... //-- ANOTHER NODE 

यह हमेशा एक टपल होने वाला है, जहां पहला तत्व आपकी निर्भरता के लिए एक इनपुट है, और अंतिम तत्व एक फ़ंक्शन है , जो उस निर्भरता का परिणाम प्राप्त करता है। टपल के उन तत्वों के बीच वह "स्थान" वह जगह है जहाँ आपकी निर्भरता फिट होगी, जैसे उन रचना उदाहरणों में, जहाँ आपके पास 'a -> 'b , 'c -> 'd और आपको एक और 'b -> 'c लगाने की आवश्यकता है। 'b -> 'c उन्हें जोड़ने के लिए बीच में 'b -> 'c ।

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

यहाँ यह कैसा दिखता है, पूर्ण स्रोत यहाँ है :

  type Program<'a> = | GetCard of CardNumber * (Card option -> Program<'a>) | GetCardWithAccountInfo of CardNumber * ((Card*AccountInfo) option -> Program<'a>) | CreateCard of (Card*AccountInfo) * (Result<unit, DataRelatedError> -> Program<'a>) | ReplaceCard of Card * (Result<unit, DataRelatedError> -> Program<'a>) | GetUser of UserId * (User option -> Program<'a>) | CreateUser of UserInfo * (Result<unit, DataRelatedError> -> Program<'a>) | GetBalanceOperations of (CardNumber * DateTimeOffset * DateTimeOffset) * (BalanceOperation list -> Program<'a>) | SaveBalanceOperation of BalanceOperation * (Result<unit, DataRelatedError> -> Program<'a>) | Stop of 'a (*{- This bind function allows you to pass a continuation for current node of your expression tree the code is basically a boiler plate, as you can see. -}*) let rec bind f instruction = match instruction with | GetCard (x, next) -> GetCard (x, (next >> bind f)) | GetCardWithAccountInfo (x, next) -> GetCardWithAccountInfo (x, (next >> bind f)) | CreateCard (x, next) -> CreateCard (x, (next >> bind f)) | ReplaceCard (x, next) -> ReplaceCard (x, (next >> bind f)) | GetUser (x, next) -> GetUser (x,(next >> bind f)) | CreateUser (x, next) -> CreateUser (x,(next >> bind f)) | GetBalanceOperations (x, next) -> GetBalanceOperations (x,(next >> bind f)) | SaveBalanceOperation (x, next) -> SaveBalanceOperation (x,(next >> bind f)) | Stop x -> fx (*{- This is a set of basic functions. Use them in your expression tree builder to represent dependency call -}*) let stop x = Stop x let getCardByNumber number = GetCard (number, stop) let getCardWithAccountInfo number = GetCardWithAccountInfo (number, stop) let createNewCard (card, acc) = CreateCard ((card, acc), stop) let replaceCard card = ReplaceCard (card, stop) let getUserById id = GetUser (id, stop) let createNewUser user = CreateUser (user, stop) let getBalanceOperations (number, fromDate, toDate) = GetBalanceOperations ((number, fromDate, toDate), stop) let saveBalanceOperation op = SaveBalanceOperation (op, stop) 

With a help of computation expressions , we now have a very easy way to build our workflows without having to care about implementation of real-world interactions. We do that in CardWorkflow module :

 (*{- `program` is the name of our computation expression. In every `let!` binding we unwrap the result of operation, which can be either `Program<'a>` or `Program<Result<'a, Error>>`. What we unwrap would be of type 'a. If, however, an operation returns `Error`, we stop the execution at this very step and return it. The only thing we have to take care of is making sure that type of error is the same in every operation we call -}*) let processPayment (currentDate: DateTimeOffset, payment) = program { (*{- You can see these `expectValidationError` and `expectDataRelatedErrors` functions here. What they do is map different errors into `Error` type, since every execution branch must return the same type, in this case `Result<'a, Error>`. They also help you quickly understand what's going on in every line of code: validation, logic or calling external storage. -}*) let! cmd = validateProcessPaymentCommand payment |> expectValidationError let! card = tryGetCard cmd.CardNumber let today = currentDate.Date |> DateTimeOffset let tomorrow = currentDate.Date.AddDays 1. |> DateTimeOffset let! operations = getBalanceOperations (cmd.CardNumber, today, tomorrow) let spentToday = BalanceOperation.spentAtDate currentDate cmd.CardNumber operations let! (card, op) = CardActions.processPayment currentDate spentToday card cmd.PaymentAmount |> expectOperationNotAllowedError do! saveBalanceOperation op |> expectDataRelatedErrorProgram do! replaceCard card |> expectDataRelatedErrorProgram return card |> toCardInfoModel |> Ok } 

This module is the last thing we need to implement in business layer. Also, I've done some refactoring: I moved errors and common types to Common project . About time we moved on to implementing data access layer.

Data access layer

The design of entities in this layer may depend on our database or framework we use to interact with it. Therefore domain layer doesn't know anything about these entities, which means we have to take care of mapping to and from domain models in here. Which is quite convenient for consumers of our DAL API. For this application I've chosen MongoDB, not because it's a best choice for this kind of task, but because there're many examples of using SQL DBs already and I wanted to add something different. We are gonna use C# driver.

For the most part it's gonna be pretty strait forward, the only tricky moment is with Card . When it's active it has an AccountInfo inside, when it's not it doesn't. So we have to split it in two documents: CardEntity and CardAccountInfoEntity , so that deactivating card doesn't erase information about balance and daily limit.

Other than that we just gonna use primitive types instead of discriminated unions and types with built-in validation.

There're also few things we need to take care of, since we are using C# library:

• Convert null s to Option<'a>
• Catch expected exceptions and convert them to our errors and wrap it in Result<_,_>

We start with CardDomainEntities module , where we define our entities:

  [<CLIMutable>] type CardEntity = { [<BsonId>] CardNumber: string Name: string IsActive: bool ExpirationMonth: uint16 ExpirationYear: uint16 UserId: UserId } with //-- we're gonna need this in every entity for error messages member this.EntityId = this.CardNumber.ToString() (*{- we use this Id comparer quotation (F# alternative to C# Expression) for updating entity by id, since for different entities identifier has different name and type -}*) member this.IdComparer = <@ System.Func<_,_> (fun c -> c.CardNumber = this.CardNumber) @> 

Those fields EntityId and IdComparer we are gonna use with a help of SRTP . We'll define functions that will retrieve them from any type that has those fields define, without forcing every entity to implement some interface:

  let inline (|HasEntityId|) x = fun () -> (^a : (member EntityId: string) x) let inline entityId (HasEntityId f) = f() let inline (|HasIdComparer|) x = fun () -> (^a : (member IdComparer: Quotations.Expr<Func< ^a, bool>>) x) //-- We need to convert F# quotations to C# expressions //-- which C# mongo db driver understands. let inline idComparer (HasIdComparer id) = id() |> LeafExpressionConverter.QuotationToExpression |> unbox<Expression<Func<_,_>>> 

As for null and Option thing, since we use record types, F# compiler doesn't allow using null value, neither for assigning nor for comparison. At the same time record types are just another CLR types, so technically we can and will get a null value, thanks to C# and design of this library. We can solve this in 2 ways: use AllowNullLiteral attribute, or use Unchecked.defaultof<'a> . I went for the second choice since this null situation should be localized as much as possible:

  let isNullUnsafe (arg: 'a when 'a: not struct) = arg = Unchecked.defaultof<'a> //-- then we have this function to convert nulls to option, //-- therefore we limited this toxic null thing in here. let unsafeNullToOption a = if isNullUnsafe a then None else Some a 

In order to deal with expected exception for duplicate key, we use Active Patterns again:

  //-- First we define a function which checks, whether exception is about duplicate key let private isDuplicateKeyException (ex: Exception) = ex :? MongoWriteException && (ex :?> MongoWriteException).WriteError.Category = ServerErrorCategory.DuplicateKey //-- Then we have to check wrapping exceptions for this let rec private (|DuplicateKey|_|) (ex: Exception) = match ex with | :? MongoWriteException as ex when isDuplicateKeyException ex -> Some ex | :? MongoBulkWriteException as bex when bex.InnerException |> isDuplicateKeyException -> Some (bex.InnerException :?> MongoWriteException) | :? AggregateException as aex when aex.InnerException |> isDuplicateKeyException -> Some (aex.InnerException :?> MongoWriteException) | _ -> None //-- And here's the usage: let inline private executeInsertAsync (func: 'a -> Async<unit>) arg = async { try do! func(arg) return Ok () with | DuplicateKey ex -> return EntityAlreadyExists (arg.GetType().Name, (entityId arg)) |> Error } 

After mapping is implemented we have everything we need to assemble API for our data access layer , which looks like this:

  //-- `MongoDb` is a type alias for `IMongoDatabase` let replaceUserAsync (mongoDb: MongoDb) : ReplaceUserAsync = fun user -> user |> DomainToEntityMapping.mapUserToEntity |> CommandRepository.replaceUserAsync mongoDb let getUserInfoAsync (mongoDb: MongoDb) : GetUserInfoAsync = fun userId -> async { let! userInfo = QueryRepository.getUserInfoAsync mongoDb userId return userInfo |> Option.map EntityToDomainMapping.mapUserInfoEntity } 

The last moment I mention is when we do mapping Entity -> Domain , we have to instantiate types with built-in validation, so there can be validation errors. In this case we won't use Result<_,_> because if we've got invalid data in DB, it's a bug, not something we expect. So we just throw an exception. Other than that nothing really interesting is happening in here. The full source code of data access layer you'll find here .

Composition, logging and all the rest

As you remember, we're not gonna use DI framework, we went for interpreter pattern. If you want to know why, here's some reasons:

• IoC container operates in runtime. So until you run your program you can't know that all the dependencies are satisfied.
• It's a powerful tool which is very easy to abuse: you can do property injection, use lazy dependencies, and sometimes even some business logic can find it's way in dependency registering/resolving (yeah, I've witnessed it). All of that makes code maintaining extremely hard.

That means we need a place for that functionality. We could place it on a top level in our Web Api, but in my opinion it's not a best choice: right now we are dealing with only 1 bounded context, but if there's more, this global place with all the interpreters for each context will become cumbersome. Besides, there's single responsibility rule, and web api project should be responsible for web, right? So we create CardManagement.Infrastructure project .

Here we will do several things:

• Composing our functionality
• App configuration
• Logging

If we had more than 1 context, app configuration and log configuration should be moved to global infrastructure project, and the only thing happening in this project would be assembling API for our bounded context, but in our case this separation is not necessary.

Let's get down to composition. We've built execution trees in our domain layer, now we have to interpret them. Every node in that tree represents some dependency call, in our case a call to database. If we had a need to interact with 3rd party api, that would be in here also. So our interpreter has to know how to handle every node in that tree, which is verified in compile time, thanks to <TreatWarningsAsErrors> setting. Here's what it looks like:

 (*{- Those `bindAsync (next >> interpretCardProgram mongoDb)` work pretty simple: we execute async function to the left of this expression, await that operation and pass the result to the next node, after which we interpret that node as well, until we reach the bottom of this recursion: `Stop a` node. -}*) let rec private interpretCardProgram mongoDb prog = match prog with | GetCard (cardNumber, next) -> cardNumber |> getCardAsync mongoDb |> bindAsync (next >> interpretCardProgram mongoDb) | GetCardWithAccountInfo (number, next) -> number |> getCardWithAccInfoAsync mongoDb |> bindAsync (next >> interpretCardProgram mongoDb) | CreateCard ((card,acc), next) -> (card, acc) |> createCardAsync mongoDb |> bindAsync (next >> interpretCardProgram mongoDb) | ReplaceCard (card, next) -> card |> replaceCardAsync mongoDb |> bindAsync (next >> interpretCardProgram mongoDb) | GetUser (id, next) -> getUserAsync mongoDb id |> bindAsync (next >> interpretCardProgram mongoDb) | CreateUser (user, next) -> user |> createUserAsync mongoDb |> bindAsync (next >> interpretCardProgram mongoDb) | GetBalanceOperations (request, next) -> getBalanceOperationsAsync mongoDb request |> bindAsync (next >> interpretCardProgram mongoDb) | SaveBalanceOperation (op, next) -> saveBalanceOperationAsync mongoDb op |> bindAsync (next >> interpretCardProgram mongoDb) | Stop a -> async.Return a let interpret prog = try let interpret = interpretCardProgram (getMongoDb()) interpret prog with | failure -> Bug failure |> Error |> async.Return 

Note that this interpreter is the place where we have this async thing. We can do another interpreter with Task or just a plain sync version of it. Now you're probably wondering, how we can cover this with unit-test, since familiar mock libraries ain't gonna help us. Well, it's easy: you have to make another interpreter. Here's what it can look like:

  type SaveResult = Result<unit, DataRelatedError> type TestInterpreterConfig = { GetCard: Card option GetCardWithAccountInfo: (Card*AccountInfo) option CreateCard: SaveResult ReplaceCard: SaveResult GetUser: User option CreateUser: SaveResult GetBalanceOperations: BalanceOperation list SaveBalanceOperation: SaveResult } let defaultConfig = { GetCard = Some card GetUser = Some user GetCardWithAccountInfo = (card, accountInfo) |> Some CreateCard = Ok() GetBalanceOperations = balanceOperations SaveBalanceOperation = Ok() ReplaceCard = Ok() CreateUser = Ok() } let testInject a = fun _ -> a let rec interpretCardProgram config (prog: Program<'a>) = match prog with | GetCard (cardNumber, next) -> cardNumber |> testInject config.GetCard |> (next >> interpretCardProgram config) | GetCardWithAccountInfo (number, next) -> number |> testInject config.GetCardWithAccountInfo |> (next >> interpretCardProgram config) | CreateCard ((card,acc), next) -> (card, acc) |> testInject config.CreateCard |> (next >> interpretCardProgram config) | ReplaceCard (card, next) -> card |> testInject config.ReplaceCard |> (next >> interpretCardProgram config) | GetUser (id, next) -> id |> testInject config.GetUser |> (next >> interpretCardProgram config) | CreateUser (user, next) -> user |> testInject config.CreateUser |> (next >> interpretCardProgram config) | GetBalanceOperations (request, next) -> testInject config.GetBalanceOperations request |> (next >> interpretCardProgram config) | SaveBalanceOperation (op, next) -> testInject config.SaveBalanceOperation op |> (next >> interpretCardProgram config) | Stop a -> a 

We've created TestInterpreterConfig which holds desired results of every operation we want to inject. You can easily change that config for every given test and then just run interpreter. This interpreter is sync, since there's no reason to bother with Task or Async .

There's nothing really tricky about the logging, but you can find it in this module . The approach is that we wrap the function in logging: we log function name, parameters and log result. If result is ok, it's info, if error it's a warning and if it's a Bug then it's an error. That's pretty much it.

One last thing is to make a facade, since we don't want to expose raw interpreter calls. Here's the whole thing:

  let createUser arg = arg |> (CardWorkflow.createUser >> CardProgramInterpreter.interpret |> logifyResultAsync "CardApi.createUser") let createCard arg = arg |> (CardWorkflow.createCard >> CardProgramInterpreter.interpret |> logifyResultAsync "CardApi.createCard") let activateCard arg = arg |> (CardWorkflow.activateCard >> CardProgramInterpreter.interpret |> logifyResultAsync "CardApi.activateCard") let deactivateCard arg = arg |> (CardWorkflow.deactivateCard >> CardProgramInterpreter.interpret |> logifyResultAsync "CardApi.deactivateCard") let processPayment arg = arg |> (CardWorkflow.processPayment >> CardProgramInterpreter.interpret |> logifyResultAsync "CardApi.processPayment") let topUp arg = arg |> (CardWorkflow.topUp >> CardProgramInterpreter.interpret |> logifyResultAsync "CardApi.topUp") let setDailyLimit arg = arg |> (CardWorkflow.setDailyLimit >> CardProgramInterpreter.interpret |> logifyResultAsync "CardApi.setDailyLimit") let getCard arg = arg |> (CardWorkflow.getCard >> CardProgramInterpreter.interpret |> logifyResultAsync "CardApi.getCard") let getUser arg = arg |> (CardWorkflow.getUser >> CardProgramInterpreter.interpretSimple |> logifyResultAsync "CardApi.getUser") 

All the dependencies here are injected, logging is taken care of, no exceptions is thrown — that's it. For web api I used Giraffe framework. Web project is here .

निष्कर्ष

We have built an application with validation, error handling, logging, business logic — all those things you usually have in your application. The difference is this code is way more durable and easy to refactor. Note that we haven't used reflection or code generation, no exceptions, but still our code isn't verbose. It's easy to read, easy to understand and hard to break. As soon as you add another field in your model, or another case in one of our union types, the code won't compile until you update every usage. Sure it doesn't mean you're totally safe or that you don't need any kind of testing at all, it just means that you're gonna have fewer problems when you develope new features or do some refactoring. The development process will be both cheaper and more interesting, because this tool allows you to focus on your domain and business tasks, instead of drugging focus on keeping an eye out that nothing is broken.

Another thing: I don't claim that OOP is completely useless and we don't need it, that's not true. I'm saying that we don't need it for solving every single task we have, and that a big portion of our tasks can be better solved with FP. And truth is, as always, in balance: we can't solve everything efficiently with only one tool, so a good programming language should have a decent support of both FP and OOP. And, unfortunately, a lot of most popular languages today have only lambdas and async programming from functional world.