Разработка домена в приложении Node.js

TL; DR; Я ищу банальный пример приложения DDD node.js.

Привет,

Я собираюсь создать приложение node. Интересно, что я не могу найти какой-либо пример приложения с бизнес-логикой, разделенной в домене.

ОК, есть несколько примеров: https://github.com/adrai/node-cqrs-domain - но это целая CQRS с реализацией событий.

Моя идея сделать это вот так:

//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. Если да, то почему? Если нет, можете ли вы отправить мне пример внедрения DDD или улучшить код?

[2017/01/13]

Я создал образец приложения в TypeScript. На данный момент без репозиториев и не много сервисов. Запросы и запросы на запрос приветствуются. https://github.com/dawiddominiak/ddd-typescript-bin-packing-problem-solution

Ответ 1

Я очень новичок в мире Node.js.

Но я считаю, что если вы выполняете свою работу с помощью TypeScript с Node, вы можете принудительно использовать большинство принципов DDD.

Проблема "и преимущество в одно и то же время" в Node.js заключается в том, что существуют не такие ограничения, как у нас на языках ООП, таких как С# или Java. и эта свобода "и грязная" JavaScript делает очень сложную сложную сложную платформу DomainModel и Business

Ответ 2

Я хочу сделать то же самое в данный момент, и я иду из мира Ruby. Итак, позвольте мне сделать 2 вещи:

Назовите вас лучшей реализацией Ruby, которую я видел для управляемого доменом дизайном Я нашел: Hanami: http://hanamirb.org/guides/models/overview/ который вы могли бы использовать в качестве ссылки.
Обсудите, что я нахожу (буквально сейчас, когда я печатаю), чтобы попытаться найти аналоги в Node.

Я нашел эту страницу: https://github.com/sindresorhus/awesome-nodejs

который каталогизирует тонну высококачественных/высокодоступных пакетов Node.

Во-первых, нам нужно что-то, что будет делать валидация и построение схемы для наших моделей доменов. Просто глядя на первую запись в разделе валидации данных, Joi кажется для этого достойным выбором:

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, вы можете закодировать объект, который будет соответствовать указанному выше интерфейсу, а затем выполняет грязную работу по интеграции с этими фреймами.

Если бы я попытался использовать разные ORM, я бы создал другой объект репо для каждого из вышеперечисленных. Обратите внимание, что, поскольку я написал это, репо - это синглтон, который знает разные сущности и как их упорствовать. Во многих случаях это, без сомнения, будет делегировать разные объекты репозитория на основе каждого объекта. Однако это может не всегда быть правдой. простое репо в памяти, может иметь массив объектов для каждого объекта.

Это оставляет Сервисы/Интеракторы - функции/классы, которые действительно работают. Это легко - это те, которые принимают объект домена, выполняют некоторую бизнес-логику и в случаях CRUD вызывают вызов в репозиторий. Вероятно, синтаксически неправильный пример:

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

для сервисных функций, я только что узнал о Node машинах, и они кажутся действительно умной идеей: http://node-machine.org

они кажутся JS-попыткой в документации monads+. поэтому я подумываю написать их так.

в любом случае, учитывая, что это был год с момента вашего сообщения, вы, вероятно, переехали. надеюсь, это поможет вам/сообществу!

Ответ 3

Многие утверждают, что JavaScript НЕ подходит для моделирования сложной проблемы в модели домена, а затем в коде. Это особенно касается случая, когда домен находится в бизнесе, промышленности и торговле, а не в компьютерной или науке о данных.

Я не говорю, что нельзя создать модель домена в JavaScript. Так же, как можно создать его в C. Но означает ли это, что нужно?

Пример, который вы даете, использует некоторую терминологию в разработке, ориентированном на домен, но пропускает всю цель и принципы применения.

Ответ 4

Я сделал репо о том, как сделать API в узле с использованием DDD, возможно, это поможет вам принять идеи.

https://github.com/nabby27/example_node_api