設計思想とプログラム

実戦的なLambda(Node.js)関数の作り方:その2

前説

その1編では、index.js の基本構造について説明しました。
今回は、業務ロジックの基本構造(設計指針)について、自分が、どんな設計を行っているのかについて説明する。
※ まだまだ手探り感満載の、投稿第2回です。イロイロと書き慣れない。。。(--A

業務ロジックの大体の構造

Node.jsは java のような純然たるオブジェクト指向の言語ではないですが、実戦で利用しようと思うと、やはり継承の概念は取り入れたくなりますよね。(ぇっ、私だけですか!?)
継承ツリーは多すぎても少なすぎても維持がし難くなるので、開発する時は、大体、上記のような3層構造にしてます。

① プロジェクト共通処理

一番、仕組的な処理や、プロジェクト全体を通しての共通処理となるため、基本、開発リーダー格やアーキテクトなどに実装・改修をお願いするファイルとなる。
メンバー開発者は、基本的にはコピペして継承して利用するだけの状態を維持する。

➁ 業務共通処理

開発する上で一番、今回紹介する構造で実装した場合は、コーディング量が多くなるファイルとなります。
Promiseの入れ子にならずに、処理ブロック(Promiseのブロック)を、あまり深い入れ子にならずに処理できる機構を、①側に実装しておくと良いでしょう。

➂ 業務固有処理

Lambda(Node.js)で実装する上では、環境変数から②への処理のパラメータ化や、②の処理を個別にオーバーライドしたい時などに、処理を実装する。
自分が書いてきたコード群の中では、比較的に短いコード量になる事が多い。しかしながら、➁の出来が悪いと全てをオーバーライドする事も、ままあるので、業務共通処理を実装する人の腕次第となる場合もある。

スポンサーリンク

-設計思想とプログラム
-, ,