[Project]開発開始構造

📁 Express 3層設計[3層アーキテクチャ]作成構造

デザインとは?

プログラミングにおけるコード設計とは、設計コード、ファイル、フォルダ構造を指す.

コードの作成中に適切な設計が行われていない場合は、いくつかの問題が発生する可能性があります.

コードは数百行(または数千行)あるので、変更するコードがある場合は見つけにくいです.これはメンテナンスの難しさを増します.

コードとコード(関数と関数の間など)の関係を一目で見るのは難しい.

各コード(関数,オブジェクトなど)の役割と機能を明確に区別していないため,機能別のテスト(ユニットテスト)は困難である.

1つのファイルを同時に複数人で修正することは困難であるため、パーティション化が困難である.

新しい機能を追加したい場合は、既存のコードの変更または再作成が必要な部分を特定するのは難しいです.これは、コードが拡張性に欠けていることを意味します.

これらの問題を解決するために,複数のコード構造設計を作成し,その中の3層構造設計を用いることにした.
三層構造設計とは、三層に分けて設計することである.

制御レイヤ(コントローラ):ユーザーのリクエストを分析し、リクエストを適切なサービスに転送し、サービス結果に再応答するレイヤ.
Routingレイヤ.
expressの場合、req.params(), req.body()、res.status()、res.send()などのコードが作成されます.
サービス層(Service Layer):コントローラから送信された要求に論理を適用する層.
論理、たとえば、ログイン・サービスの場合:
if-elseなどの次のコードで、次の論理を実現できます.
≪モデル・レイヤ(データ)｜Model Layer(Data)｜oem_src≫:サービス・レイヤからデータベースにアクセスする必要がある場合があります.データに関連するコードが作成されます.Mongooseについては、モデルです.find({})などのコードが作成されます.
ログインサービスが一例である場合は、要求されたIDがデータベースに存在することを確認し、存在する場合は、データベースに格納されたパスワードが要求された(ユーザが入力した)パスワードと一致する必要があります.
サービス・レイヤは、データ・レイヤにデータベース検証要求を発行します.
コードをロールごとに分離し、各レイヤで実装する場合、次の利点があります.

各ロールは開発タスクを分担することができ、分業を簡素化します.

役割による開発タスクの割り当てではなくMVPによる開発タスクであっても、各MVPがどのようなプロセスで実現されるか(Controllerでユーザの要求を受信し、要求に対してService層で論理を実施し、必要に応じてデータベースにアクセスし、結果としてControllerで応答する)、コード構造が容易に理解できるようになる.

ルーティング関連コードはControllerフォルダにあり、サービスロジック関連コードはServiceフォルダにあり、データ関連コードはModelフォルダにあり、必要なコードを迅速に検索することができ、メンテナンスを簡素化することができる.

Webサービスの実施形態を変更する場合、たとえば、データベースをMongodbからMysqlに変更すると、各フォルダには独立した役割があります.したがって、Modelフォルダコードを変更するだけで、残りのControllerフォルダとServiceフォルダを変更する必要はありません.メンテナンスが容易です.

コードは機能別に区分されているので、機能別のテスト(ユニットテスト)を容易に行うことができる.

そこで、現在のフォルダ構造をこの3層設計を使用するように設定します.

└───src
    ├───db           # Model layer
    │   ├───models
    │   └───schemas
    ├───middlewares
    ├───routers     # Control layer
    └───services    # Service layer

💻 賞履歴[Award]部分DB設計を行う

当初の設計では、User DBに賞履歴を載せる方式で行われていましたが、賞管理を行う際には、同時にUser DB部分を見る必要があるという点で不便なので、User ModelとAward Modelを分けてAwardモデルでUserModelを参照して行いました.

import mongoose from "mongoose";
const Schema = mongoose.Schema;
const model = mongoose.model;
const AwardSchema = new Schema({
  id: {
    type: String,
    unique: true,
    required: true,
  },
  title: {
    type: String,
    required: true,
  },
  description: String,
  author: {
    type: Schema.Types.ObjectId,
    ref: "User",
    required: true,
  },
});
const AwardModel = model("Award", AwardSchema);
export { AwardSchema, AwardModel };

また、Awardモデルのように、教育[学歴部分API]のモデルも設定しました.

💾 CommitメッセージでGitLabイベントを閉じる

Gitlabホットスポットを生成する場合、ホットスポット番号が指定されます.Commitを実行するときに、特定のコマンドとホットスポット番号を使用して、Commitを実行するときにホットスポットを自動的に閉じることができます.
イベント番号が＃79の場合、"close #79"または"fix #79"と入力すると、コミットは自動的にイベントを閉じます.
他の方法で閉じるか追加する場合は、config/gitlab.ymlのissue_closing_patternで指定できます.

📒 に感銘を与える

DBデザインは頭の中で思いついたことから始まり、結局DBを見直すことになった.
最初からDBデザインを作成して、やるべきことを事前に考えておけば、修正することを解消したり減らしたりできるので、次回は必ず計画通りに設計して、それから案を立てましょう.
そして作成、提出、統合した後、私は直接この話題を閉じましたが、GitLabが書いたこの話題がcommitで自動的に閉じることができることを知っていたので、私が使っているツールの機能を改めて感じました.
最初の三層構造設計に従ってフォルダを区切って、それからコードを書いて、ここで書いて、そこで書いて、最初は混乱して、疲れましたが、適応してから、編集したい部分は修正すればいいと思います.これはいつもの場所で書くよりずっと便利です.
後で他のプロジェクトを行う場合も、他の構造を使ってみましょう.