Domain Driven Design w aplikacji Node.js

Question

TL; DR; Poszukuję banalnego przykładu aplikacji node.js DDD.

---

Cześć,

Zamierzam stworzyć aplikację węzła. Zastanawiam się, że nie mogę znaleźć żadnego przykładu aplikacji z logiką biznesową oddzieloną w domenie.

OK, istnieje kilka przykładów takich jak: https://github.com/adrai/node-cqrs-domain - ale jest to całe CQRS z wdrożeniem w zakresie zaopatrywania w wydarzenia.

Mój pomysł jest, aby to zrobić tak:

//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(); 
} 

ale z drugiej strony nigdy nie widziałem żadnego podobnego rozwiązania (z modelu domeny, model ORM, repozytorium i mappers). Czy ja myślę we właściwy sposób? Być może nie ma powodu, aby oddzielać logikę biznesową w domenie w aplikacjach node.js. Jeśli tak, dlaczego? Jeśli nie, czy możesz przesłać mi przykład wdrożenia DDD lub poprawić mój kod?

[13.01.2017]

Utworzyłem przykładowa aplikacja w maszynopisie. Na razie bez repozytoriów i niewiele usług. Problemy i prośby o ściągnięcie są mile widziane. https://github.com/dawiddominiak/ddd-typescript-bin-packing-problem-solution

Answer 1

Jestem bardzo nowy w świecie Node.js.

Ale wierzę, że jeśli wykonasz swoją pracę używając TypeScript z Node możesz wymusić stosowanie większości zasad DDD.

Problem "i przewaga w tym samym czasie" w pliku node.js, który nie ma ograniczeń takich jak w językach OOP, takich jak C# lub Java. i ta wolność „i niechlujny” JavaScriptu podejmowania stworzyć solidną złożony model domeny i logiki biznesowej bardzo ciężko

Answer 2

Wiele osób twierdzi, że JavaScript NIE jest odpowiedni do modelowania złożonego problemu w modelu domeny, a następnie do kodu. Dzieje się tak zwłaszcza wtedy, gdy domena jest w biznesie, przemyśle i handlu, a nie w komputerach lub naukach o danych.

Nie twierdzę, że nie można utworzyć modelu domeny w kodzie JavaScript. Tak jak można stworzyć jeden w C. Ale czy to znaczy, że należy?

Podany przykład używa pewnej terminologii w projektowaniu opartym na domenie, ale pomija cały cel i etos jej zastosowania.

Answer 3

szukam zrobić to samo w tej chwili, a ja idę ze świata Ruby. Więc, pozwól mi zrobić 2 rzeczy:

1. Punkt do najlepszej realizacji Ruby widziałem od Domain-Driven Design znalazłem, Hanami: http://hanamirb.org/guides/models/overview/ które można wykorzystać jako punkt odniesienia.

2. Porozmawiaj o tym, co znajduję (dosłownie teraz, kiedy piszę), aby znaleźć analogi w węźle.

Znalazłem tę stronę: https://github.com/sindresorhus/awesome-nodejs

który kataloguje mnóstwo wysokiej jakości opakowań node/wysokiej popularność.

Przede wszystkim potrzebujemy czegoś, co zrobi sprawdzanie poprawności i budowę schematu dla naszych modeli domen. Po prostu patrząc na pierwszej pozycji w sekcji walidacji danych, Joi wydaje się być przyzwoity wybór, że:

https://github.com/hapijs/joi

zakresie trwałości obiektów domeny, jestem po prostu utworzenie obiektu skrótową, pożyczając od interfejs Hanami za:

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 

, czy zdecydować się na stosowanie Bookshelf, Sequelize, a nawet ramy LoopBack można zakodować obiektu, który ma dopasować powyższy interfejs, który następnie robi brudną robotę integracji z tymi ramami.

Gdybym miał wypróbować różne ORM, utworzyłbym inny obiekt repo dla każdego z powyższych. Zauważ, że tak jak to napisałem, repo jest singletonem, który jest świadomy różnych bytów i jak je utrzymywać. W wielu przypadkach będzie to niewątpliwie przekazywać do różnych obiektów repozytorium w zależności od jednostki. Jednak nie zawsze tak jest. proste repozytorium w pamięci, może po prostu mieć szereg obiektów dla każdej jednostki.

Zostawia to Usługi/Interakcje - Funkcje/klasy, które faktycznie działają. Są one łatwe - to one pobierają obiekt domeny, wykonują logikę biznesową, a w przypadkach CRUD wywołują wywołanie repozytorium. Prawdopodobnie-składniowo-zły przykład:

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 

do funkcji serwisowych, właśnie dzisiaj dowiedziałem się o Maszyn węzła i oni wydawać się naprawdę inteligentny pomysł: http://node-machine.org

wydają się być JS-próba w monadach + dokumentacja. więc rozważam napisanie ich w ten sposób.

mimo to, biorąc pod uwagę, że minął rok od twojego wpisu, prawdopodobnie przeniosłeś się dalej. mam nadzieję, że to pomoże tobie/społeczności!