Diseño impulsado por dominio en Nodo.aplicación js

TL; DR; Estoy buscando un ejemplo trillado de nodo DDD.aplicación js.

Hola,

Voy a crear una aplicación de nodo. Me pregunto que no puedo encontrar ningún ejemplo de aplicación con lógica de negocio separada en dominio.

OK, hay algunos ejemplos como: https://github.com/adrai/node-cqrs-domain - pero esto es todo CQRS con implementación de aprovisionamiento de eventos.

Mi idea es hacer eso así: 

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

Pero por otro lado Nunca he visto una solución similar (con modelo de dominio, modelo or, repositorio y mapeadores). ¿Estoy pensando de la manera correcta? Tal vez no hay razón para separar la lógica de negocio en el dominio en el nodo.js applications. Si es así, ¿por qué? Si no, ¿puedes enviarme un ejemplo de implementación de DDD o mejorar mi código?

[2017/01/13]

He creado una aplicación de ejemplo en TypeScript. Por ahora sin repositorios y sin muchos servicios. Los problemas y las solicitudes de extracción son Bienvenidas. https://github.com/dawiddominiak/ddd-typescript-bin-packing-problem-solution

Author: Dawid Dominiak, 2015-12-01
Source

3 answers

Soy muy nuevo en Node.js world.

Pero creo que si haces tu trabajo usando TypeScript con Node puedes forzar el uso de la mayoría de los principios DDD.

El problema "y ventaja al mismo tiempo" en el nodo.js que no hay restricciones como las que tenemos en lenguajes de programación orientada a objetos como C# o Java. y esta libertad" y desordenada " de JavaScript haciendo crear un modelo de dominio complejo robusto y una lógica de negocios muy difícil

 3
Author: Wahid Bitar,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-02-26 15:44:50

Estoy buscando hacer lo mismo en este momento, y vengo del mundo Ruby. Por lo tanto, permítanme hacer 2 cosas:

  1. Apunta a la mejor implementación de Ruby que he visto de Diseño Basado en Dominios que he encontrado, Hanami: http://hanamirb.org/guides/models/overview / que podrías usar como referencia.

  2. Discuta lo que estoy encontrando (literalmente ahora mismo, mientras escribo) para intentar encontrar los análogos en el Nodo.

He encontrado esta página: https://github.com/sindresorhus/awesome-nodejs

Que cataloga una tonelada de paquetes de nodos de alta calidad / alta popularidad.

Lo primero es que necesitamos algo que haga validación y construcción de esquemas para nuestros Modelos de Dominio. Solo mirando la primera entrada en la sección de validación de datos, Joi parece ser una opción decente para eso:

Https://github.com/hapijs/joi

Para la persistencia de los objetos de dominio, solo estoy configurando un objeto stub, tomado prestado de la interfaz de 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

Si elige utilizar Bookshelf, Sequelize, o incluso el framework LoopBack, puede codificar un objeto que se ajuste a la interfaz anterior que luego hace el trabajo sucio de integrarse con esos frameworks.

Si tuviera que probar diferentes OR, crearía un objeto repo diferente para cada uno de los anteriores. Observe que, como he escrito, el repo es un singleton que es consciente de las diferentes entidades y cómo mantenerlas. En en muchos casos, esto sin duda delegará a diferentes objetos de repositorio por entidad. Sin embargo, eso puede no ser siempre cierto. un simple repositorio en memoria, podría tener una matriz de objetos para cada entidad.

Que deja Servicios/Interactors - Las funciones/clases que realmente funcionan. Estos son fáciles: son los que toman un objeto de dominio, realizan alguna lógica de negocio y, en los casos CRUD, hacen una llamada al Repositorio. Un probablemente-sintácticamente-equivocado ejemplo:

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

Para las funciones de servicio, acabo de aprender sobre las Máquinas de nodos, y parecen una idea realmente inteligente: http://node-machine.org

Parecen ser un intento de JS de mónadas + documentación. así que estoy considerando escribirlos así.

De todos modos, dado que ha pasado un año desde su publicación, probablemente haya seguido adelante. espero que esto le ayude a usted / la comunidad!

 2
Author: MissingHandle,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-04-05 03:59:59

Muchos argumentarían que JavaScript NO es muy adecuado para modelar un problema complejo en un modelo de dominio y luego en código. Ese es especialmente el caso si el dominio se encuentra en los negocios, la industria y el comercio, en lugar de en la informática o la ciencia de datos.

No estoy diciendo que uno no pueda crear un modelo de dominio en JavaScript. Como uno podría crear uno en C. Pero eso no significa que uno debe?

El ejemplo que usted da utiliza cierta terminología en el diseño basado en dominios, pero se pierde todo propósito y ethos de aplicarlo.

 1
Author: aryeh,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2016-04-18 08:28:44