NestJSと戦術的DDDのいいとこどりをしてバックエンドTypescriptの設計をした話
はじめに バックエンド開発にもTypeScriptを利用する事例、増えてますね。NestJSはTypescriptバックエンドの中でも、唯一のopinionatedなフレームワークとして採用しました（特に大規模な開発を目指している弊社では相性がいい）。しかし、実際にNestJSを使って開発を進めると「too much」と言われる前評判とは異なり、「not enough」という印象を受けました。特に、DDDの観点からすると、DTO（Data Transfer Object）やControllerなどプレゼンテーション層は整備されているものの、Service層にユースケース層、ドメイン層、インフラ層の役割を一括して詰め込んでしまい、結果として「Fat Service」になりがちです。 そこで、本記事ではNestJSの機能を活かしつつ、戦術的DDDのパターンを導入して、Service以下のコード
TypeScriptで実践するドメイン駆動設計（DDD）
初めに モチベーション 私はこれまでドメイン駆動設計で設計されたシステムの開発案件に参画した経験はありますが、1からドメイン駆動設計で設計での設計を行った経験がありませんでした。そのため個人でシステムを開発している際に設計に悩むことがあり、自身で1からドメイン駆動設計ベースの設計ができるようになることを目指して学習を進め、その過程で得た知見をまとめています。 特に以下のような点に焦点を当てています。 ドメイン駆動設計の理論をTypeScriptのコードベースで理解する 既存のドメイン駆動設計システムを理解するだけでなく、新規設計ができるようになるための知識の整理 ドメイン駆動設計(DDD)とは ドメインとは「システムが対象とする業務領域」のことです。 例えばECサイトでは商品管理、在庫、注文、配送などがドメインとなります。 ドメイン駆動設計の本質は、このような現場の業務知識やルールを深く理
TypeScriptで学ぶ！SOLID原則
はじめに 皆さんこんにちは、株式会社エムアイ・ラボのエンジニアです！ 今回はソフトウェア設計のSOLID原則について学習したので、弊社のメインの開発言語であるTypeScriptのサンプルコードを使って共有できればと思います。 SOLID原則は、オブジェクト思考プログラミングにおいて、ソフトウェアがメンテナンスしやすく、拡張や変更に強いソフトウェア設計を行うための原則です。 SOLID原則にはSOLIDの頭文字をそれぞれとった、５つの原則があります。 単一責任の原則（Single Responsibility Principle） 単一責任の原則とは、クラスが一つの機能や責任を持つべきで、クラスが変更される理由は一つであるべきというです。 クラスが一つの機能や責任のみを持つようにすることにより、コードは再利用可能でテストが容易になります。 単一責任の原則を遵守している例 以下のBirdクラ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
