なぜ私の本はノードを使用します.jsとJavaScript

このポストはなぜ私がノードを選んだかを説明します.私の本"Implementing DDD, CQRS and Event Sourcing"のためのプログラミング言語としてのランタイムプラットホームとJavaScriptとしてのjs.説明された理由は、個人的な経験、望ましい目標聴衆だけでなく、プラットホームと言語特性を取り入れます.また,静的型の利点と意味を簡単に論じた.最後に、ポストは既存の本に将来の追加の見通しを閉じます.

経験
ノードを使用する1つの理由.私の本のJSとJavaScriptは、私はほぼ8年間の両方で働いていることです.JavaScriptはプログラミング言語として、私は約14年の経験を持っています.また、私がCQRSとイベントソーシングを適用した2つのプロジェクトは、それらの技術を使用しました.したがって、私は技術的な本を書く予定だったとき、私にとって自然な選択のようでした.

幅広い聴衆
JavaScriptのもう一つの理由は、それが広い視聴者に達することができる非常に普及した言語であるということです.誰もが好きではないが、それを理解する多くの人々がいる.また、その構文はJavaやCのような他の言語と似ています.特定の目的のために独特の特性を持つプログラミング言語がある間、JavaScriptの使用は単に高い範囲を可能にします.
構文の類似性については、JavaScriptの典型的なアプリケーションサービスクラスです.

class NoteApplicationServices {

  #noteRepository;

  constructor({noteRepository}) {
    this.#noteRepository = noteRepository;
  }

  async createNote({noteId, content, category}) {
    const note = new Note({id: noteId, content, category});
    await this.#noteRepository.save(note);
  }

  /* .. */

}

Javaでの等価(ブロック)実装は、その型の注釈で異なります.

public class NoteApplicationServices {

  private NoteRepository noteRepository;

  constructor(NoteRepository noteRepository) {
    this.noteRepository = noteRepository;
  }

  public void createNote(UUID noteId, string content, string category) {
    Note note = new Note(noteId, content, category);
    this.noteRepository.save(note);
  }

  /* .. */

}

この構文の類似性は、Cのような他のプログラミング言語、例えばCやPHPでも与えられます.

ユニバーサル言語
私の本は、ユーザーインターフェイスの部分に専用の章が含まれます.また、すべてのクライアント側のコードにJavaScriptを使用します.これはブラウザでネイティブにサポートされているため、おそらくWebフロントエンドのための最も使用される言語です.さらに、サーバーとクライアントの両方で消費されるユニバーサルインフラストラクチャコードがあります.このアプローチで、リーダーはバックエンドとフロントエンドコードを理解するために1つの言語を知っている必要があります.

簡易
長年にわたって、私はバックエンドのための複数の言語、ランタイムとサーバーで働いてきました.専門的には、PHPとApacheを使用しました.ノードから始めたとき.JS、私は特定のユースケースのための最小限のオーバーヘッドに感銘を受けました.同時に、特にサードパーティ製のライブラリを使用して複雑な生産グレードのソフトウェアを構築するために適して感じた.全体的に、それはしばしば私の本の実装に適しています.
例として、HTTPファイルシステムインターフェイスを作成するための簡易ファクトリを見てみましょう.

const createHttpFilesystemInterface = pathResolver =>
  async (request, response) => {
    const filePath = pathResolver(request);
    try {
      await stat(filePath);
      const fileExtension = path.extname(filePath);
      const contentType = contentTypeByExtension[fileExtension] || 'text/plain';
      response.writeHead(200, {'Content-Type': contentType});
      createReadStream(filePath).pipe(response);
    } catch (error) {
      response.writeHead(404);
      response.end();
    }
  };

const contentTypeByExtension = {
  '.js': 'application/javascript',
  '.html': 'text/html',
  '.css': 'text/css',
};

// example usage
const httpFilesystemInterface = createHttpFilesystemInterface(
  request => `${rootDirectory}/${url.parse(request.url).pathname}`);
http.createServer(httpFilesystemInterface).listen(50000);

これはそのノードを例示することではありません.JSは一般的に物事をより簡単にする.しかし、多くのプラットフォームコードが含まれて多くのプラットフォームがあります.

簡潔でコンパクトなコード
私の本のコード例はコンパクトでなければなりません.特にPDFバージョンでは、85文字の行の長さ制限があります.JavaScriptは簡潔でコンパクトなコードを書くことができます.しばしば、これは最小のオーバーヘッドまたは儀式のために単純なものの場合です.その上に、コードを短く保つのを助ける特定の言語構成があります.いくつかの例は、矢印関数式、オブジェクトリテラル、短縮プロパティ名、および破壊課題です.
以下の例では、単純な値型の実装を示します.

const Money = function({value, currency}) {
  Object.freeze(Object.assign(this, {value, currency}));
};

一見して、例はさらに複雑に見えるかもしれません.また、匿名オブジェクトを作成し、フリーズした矢印関数を実装することもできます.しかしながら、上記の実装はクラスベースの言語の完全なクラスに匹敵する.コンストラクター関数は、その型をチェックできるインスタンスを返します.例えば、new Money({value: 10, currency: 'USD'}) instanceof Moneyはtrueである.

タイプは?
JavaScriptは動的にタイプされた言語です.他の方法でラウンドを置く、それは静的なタイピングを欠いている.これは利点として、またはショートとして見ることができます.DDDと複雑なドメインのモデリングに関しては、おそらく不利です.複雑なドメインモデルの実装は、静的タイピングと強力なタイプシステムから利益を得ます.私の本の例では、コードがコンパクトに保つので、型の不在は実際に有利です.
強力な静的型システムの利点の例として、次のドメインモデル実装を見てください.

type Author = {id: UUID, firstName: string, lastName: string};
type Grade = 'A' | 'B' | 'C' | 'D' | 'E' | 'F';

type ExamResult = {author: Author, grade: Grade};

タイプGradeは、タイプレベルのグレードのドメイン固有の概念を表します.正しい値を確保するために必要なランタイムチェックはありません.ドメイン層とは別に、他のソフトウェア部品は静的な型からあまり恩恵を受けないかもしれません.また、些細なドメイン問題はプレーンJavaScriptで適切に解決されるかもしれません.その上に、ランタイムタイプチェックの可能性があります.一般に、typescriptの使用は不利でありません.同時に、普通のJavaScriptも十分です.

なぜ他に何か?
私の本のために使用するプログラミング言語とランタイムのための多くの選択肢があったでしょう.ノード.JSとJavaScriptは一般的にDDD、CQRSまたはイベントのソーシングを適用するために優れていません.前述のように、プレーンJavaScriptは、静的なタイプの欠如のために複雑なドメイン問題に取り組むのに適していることさえできません.しかし、2つは私の本にふさわしい選択であることを証明しました.最後に、ほとんどの例の実装は、とにかく他のテクノロジに簡単にマップできます.

本の計画
本に取り組んでいる間、私は時々、タイプスクリプトまたは技術の全体的な選択を使用しないことについて心配しました.私の心を和らげるために、私は将来の版について、または、Nodeなしで錆さえ使用することについて考えました.js今現在、私は、これが必要であると思いません.しかし、有用な将来の追加の可能性があります.私の短期計画は、タイプの利点に関する付録を書くか、既存の影響された内容に注釈を付けることです.
Buy the book
当初は、2020年12月21日にhttps://www.alex-lawrence.comで発行された.