डोमेन संचालित डिजाइन Node.js में अनुप्रयोग

Question

टीएल; डॉ; मैं डीडीडी node.js एप्लिकेशन के पतंग उदाहरण की तलाश में हूं।

---

हाय,

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

ठीक है, कुछ उदाहरण हैं जैसे: https://github.com/adrai/node-cqrs-domain - लेकिन यह सोर्सिंग कार्यान्वयन के साथ पूरे सीक्यूआरएस है।

मेरा विचार है कि इस तरह करना है:

//domain/book.js 
function Book(title, author) 
{ 
    this._title = title; 
    this._author = author; 
} 

// domain methods ... 

//infrastructure/persistance/repository/book-repository.js 
function BookRepository() 
{} 

BookRepository.prototype.save(book) 
{ 
    var bookModel = mappers.mapToOrm(book); 
    return bookModel.save(); 
} 

// [...] get, getAll, getNextId 

//infrastructure/persistance/orm/book.js 
//using http://bookshelfjs.org/ 
var Book = bookshelf.Model.extend({ 
    tableName: 'books' 
}); 

//infrastructure/mappers/book-mapper.js 
function mapToOrm(book) { 
    //mapping [...] 
    return new persistance.Book(); 
} 

function mapToDomain(domain) { 
    //mapping [...] 
    return new domain.Book(); 
} 

लेकिन दूसरी ओर मैं किसी भी इसी तरह समाधान (डोमेन मॉडल, ORM मॉडल, भंडार और मानचित्रकारों से) कभी नहीं देखा। क्या मैं सही तरीके से सोच रहा हूँ? शायद node.js अनुप्रयोगों में डोमेन में व्यावसायिक तर्क को अलग करने का कोई कारण नहीं है। यदि हां, तो क्यों? यदि नहीं, तो क्या आप मुझे डीडीडी कार्यान्वयन का एक उदाहरण भेज सकते हैं या अपना कोड सुधार सकते हैं?

[2017/01/13]

मैं टाइपप्रति में नमूना आवेदन बना लिया है। अब बिना भंडार के और अधिक सेवाओं के लिए। मुद्दे और पुल अनुरोधों का स्वागत है। https://github.com/dawiddominiak/ddd-typescript-bin-packing-problem-solution

Answer 1

मैं नोड.जेएस दुनिया के लिए बहुत नया हूं।

लेकिन मेरा मानना ​​है कि यदि आप का उपयोग करके अपना काम करते हैं तो नोड के साथ टाइपस्क्रिप्ट आप उपयोग किए जाने वाले अधिकांश डीडीडी सिद्धांतों को मजबूर कर सकते हैं।

समस्या "और एक ही समय में लाभ" node.js में है कि हमारे पास ऐसे प्रतिबंध नहीं हैं जैसे ओओपी भाषाओं जैसे सी # या जावा में हैं। और जावास्क्रिप्ट की यह आजादी "और गन्दा" मजबूत जटिल डोमेन बनाने और व्यापार तर्क बहुत कठिन बनाने के लिए

Answer 2

कई लोग तर्क देंगे कि जावास्क्रिप्ट एक जटिल मॉडल को डोमेन मॉडल में और फिर कोड में मॉडलिंग के लिए उपयुक्त नहीं है। यह विशेष रूप से मामला है यदि डोमेन व्यवसाय या उद्योग विज्ञान के बजाए व्यवसाय, उद्योग और वाणिज्य में है।

मैं नहीं कह रहा हूं कि जावास्क्रिप्ट में कोई डोमेन मॉडल नहीं बना सकता है। जैसे कि कोई सी में एक बना सकता है लेकिन क्या इसका मतलब है कि किसी को चाहिए?

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

Answer 3

मैं इस समय एक ही चीज़ करना चाहता हूं, और मैं रूबी दुनिया से आ रहा हूं। तो, मुझे 2 बातें करते हैं: http://hanamirb.org/guides/models/overview/ जो आपको एक संदर्भ के रूप में इस्तेमाल कर सकते हैं:

1. सबसे अच्छा रूबी कार्यान्वयन मैं के डोमेन संचालित डिजाइन मैं पाया है देखा है, Hanami को इंगित करें आप।

2. नोड में एनालॉग खोजने का प्रयास करने के लिए मुझे जो मिल रहा है (सचमुच अभी, जैसा कि मैं टाइप करता हूं) पर चर्चा करें।

मैं इस पृष्ठ पाया है: https://github.com/sindresorhus/awesome-nodejs

जो उच्च गुणवत्ता/उच्च लोकप्रियता नोड संकुल की एक टन कैटलॉग।

पहली बात यह है कि हमें कुछ ऐसे डोमेन की आवश्यकता है जो हमारे डोमेन मॉडल के लिए सत्यापन और स्कीमा निर्माण करने जा रहे हैं।

https://github.com/hapijs/joi

डोमेन वस्तुओं की हठ के लिए, मैं सिर्फ एक ठूंठ वस्तु सेट कर रहा हूं, से उधार: बस डेटा सत्यापन खंड में पहली प्रविष्टि को देख, जॉय उस के लिए एक सभ्य चुनाव हो रहा है Hanami के इंटरफ़ेस:

var repo = { 
    find: function(entity_name, id) { 
    // - Fetch an entity from the collection by its ID 
    }, 
    create: function(entity_name, data) { 
    // – Create a record for the given data and return an entity 
    }, 
    update: function(entity_name, id, data) { 
    // – Update the record corresponding to the id and return the updated entity 
    }, 
    delete: function(entity_name, id) { 
    // – Delete the record corresponding to the given entity 
    }, 
    all: function(entity_name) { 
    // - Fetch all the entities from the collection 
    }, 
    query: function(entity_name, query_object) { 

    }, 
    first: function(entity_name) { 
    // - Fetch the first entity from the collection 
    }, 
    last: function(entity_name) { 
    // - Fetch the last entity from the collection 
    }, 
    clear: function(entity_name) { 
    // - Delete all the records from the collection 
    } 
} 

module.exports = repo 

आप Bookshelf, Sequelize, या यहाँ तक LoopBack ढांचे का उपयोग करने के लिए चुनते हैं, तो आप एक वस्तु है कि इसके बाद के संस्करण इंटरफ़ेस है कि फिर उन चौखटे के साथ एकीकृत करने के गंदे काम करता है फिट करने के लिए जा रहा है कोड कर सकते हैं।

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

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

const repository = require('./myFileRepository') 

function createBook(bookEntity) { 

    if(bookEntity.valid?) { 
    repository.create('book', bookEntity) 
    return true 
    } 
    else { 
    return { error: 'book not valid' } 
    } 
} 

module.exports = createBook 

सेवा कार्यों के लिए

, मैं सिर्फ आज नोड मशीनें के बारे में सीखा है, और वे वास्तव में एक स्मार्ट विचार की तरह लग रहे हैं: http://node-machine.org

वे एक जे एस-प्रयास होने लगते हैं monads + दस्तावेज पर। इसलिए मैं उन्हें इस तरह लिखने पर विचार कर रहा हूं।

वैसे भी, यह आपकी पोस्ट के बाद से एक वर्ष रहा है, आप शायद आगे बढ़ गए हैं। उम्मीद है कि यह आपको/समुदाय की मदद करता है!