web-dev-qa-db-ja.com

Node.jsアプリケーションのドメイン駆動設計

TL; DR; DDD node.jsアプリケーションの些細な例を探しています。

こんにちは、

ノードアプリケーションを作成します。ドメインで分離されたビジネスロジックを持つアプリケーションの例を見つけることができないのだろうか。

OK、次のような例があります： 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();
}

しかしその一方で、（ドメインモデル、オームモデル、リポジトリ、マッパーを使用した）同様のソリューションを見たことはありません。私は正しい方法で考えていますか？ node.jsアプリケーションのドメインでビジネスロジックを分離する理由はないかもしれません。もしそうなら、なぜですか？そうでない場合は、DDD実装の例を送信したり、コードを改善したりできますか？

[2017/01/13]

TypeScriptでサンプルアプリケーションを作成しました。現時点では、リポジトリもサービスもあまりありません。問題とプルリクエストは大歓迎です。 https://github.com/dawiddominiak/ddd-TypeScript-bin-packing-problem-solution

javascriptnode.jsdomain-driven-design
32
Dawid Dominiak

私はNode.jsの世界に非常に新しいです。

ただし、TypeScript with Nodeを使用して作業を行うと、ほとんどのDDD原則を強制的に使用できると思います。

Node.jsの問題であり、C＃やJavaのような言語のようなOOP言語のような制限はない。 堅牢で複雑なDomainModelとビジネスロジックを非常に困難に作成する

6
Wahid Bitar

私は今も同じことをしようと思っており、Ruby世界から来ています。だから、2つのことをさせてください：

  1. 最高のRuby私が見つけたドメイン駆動設計の実装を見ました、花見： http://hanamirb.org/guides/models/overview/ これを参照として使用できます。

  2. 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 Machinesについて学びました。これらは本当に賢いアイデアのようです： http://node-machine.org

モナド+ドキュメントでのJSの試みのようです。そのようにそれらを書くことを検討しています。

とにかく、投稿してから1年が経過したので、おそらく先に進んだでしょう。これがあなた/コミュニティに役立つことを願っています！

4
MissingHandle

多くの人は、JavaScriptが複雑な問題をドメインモデルに、そしてコードにモデル化するのにあまり適していないと主張します。これは、ドメインがコンピューターサイエンスやデータサイエンスではなく、ビジネス、産業、商業に属している場合に特に当てはまります。

JavaScriptでドメインモデルを作成できないと言っているのではありません。 Cで作成できるように。しかし、そうする必要があるということですか？

この例では、ドメインドリブン設計でいくつかの用語を使用していますが、それを適用する目的と精神をすべて逃しています。

0
aryeh