フロントエンド開発をしていると、どういうアーキテクチャが良いのだろうかと迷うことはありませんか？そんな悩めるフロントエンジニアのために、今回から何回かに分けて、株式会社TAIANのフロントエンド開発で採用している Yagyu.js について紹介していきたいと思います。
この記事はどんな組織向け？
- フロントエンドのコードを全体的に整理整頓し、保守しやすい状態を保ちたい
- フロントエンドとバックエンドでタスクに偏りがある
- フロントエンドエンジニアとバックエンドエンジニアの人数に偏りがある
- フロントエンドとバックエンドの垣根を超えて開発をしたい
効率の良い開発とは
バックエンドの言語にTypeScriptを採用し、フロントエンドとバックエンドの言語を揃えることで、フロントもバックもどちらもコードを書けるようにしようという記事をよく見かけます。確かにTypeScriptを採用すると言語の意味では統一は図られますが、シングルスレッドでノンブロッキングな処理はフロントエンドとは別の書き方が求められるため、結局のところフロントエンドエンジニアとバックエンドエンジニアが垣根をこえてタスクをこなすのは難しさがあります。
今回紹介する Yagyu.js は、言語を揃えるのではなく、アーキテクチャを揃えることで開発効率を上げるアプローチとなります。フロントエンドとバックエンドの言語が統一されている必要はありません。
フロントエンドとバックエンドのアーキテクチャを揃える
フロントエンドのアーキテクチャというと、デファクトスタンダードと言えるような王道のものは見当たりません。実際Reactの公式も推奨するアーキテクチャは提唱していません。一方でバックエンドのフレームワークというと、ドメイン駆動設計（DDD）やクリーンアーキテクチャ、CQRSなど言語の壁を超えた王道のアーキテクチャが存在します。そこで今回考えられたのが、フロントエンドにバックエンドの王道アーキテクチャを取り入れた Yagyu.js になります。フロントエンドとバックエンドの障壁は言語の違いではなく、アーキテクチャの違いによるものであるという仮説のもと、以下のイメージのようなことが実現可能かチャレンジしました。
従来
Yagyu.js
取り組んでみた感想
良かったこと
- UIとビジネスロジックを完全に分離することができ、tsxファイルがシンプルになった
- 散らばっていたビジネスロジックの書く場所が整理され、どこに書くか迷わなくなった
- ドメイン駆動設計を意識することで、ビジネスサイドやドメイン知識の理解が深まった
- バックエンドエンジニアとフロントエンドエンジニアの会話が一段深まった
- コードから仕様が読み取りやすくなった
- 単体テストが書きやすくなった
- 開発を複数人で分担して進められるようになり、フロント・バック相互にヘルプができる環境になった
- その他にもフロントエンドDDDの記事にもあるように、コードを書く上での共通の価値観やコードレビューの負担軽減などもありました。
悪かったこと
- ファイル数や記述量が増えた
- フロントエンドエンジニアにとってドメイン駆動設計やオブジェクト指向の学習コストがかかった
悪かったことも裏を返すと
- AIエージェント的には責務が分離されているので逆に好都合
- ドメイン駆動設計やオブジェクト指向を学習済みのエンジニアが採用できれば即戦力になる
次回
ここまでざっくり概要を書きましたが、次回は具体的な Yagyu.js の内容について書いていこうと思います。お楽しみに。
We are hiring!
TAIANでは、このような開発・技術・思想に向き合い、未来をつくる仲間を一人でも多く探しています。少しでも興味を持っていただいた方は弊社の紹介ページをご覧ください。
株式会社TAIANのテックブログです。ブライダル業界向けのVertical SaaSを中心に、お祝いに関するプロダクトを開発中。「日本の未来をもっとアツく、あたたかく」そんな意気込みのメンバーで投稿しています。
Discussion