概要
TS製。既存の設計論と関数型プログラミングを参考に再設計されたWebアプリケーションスキーマ(と規定されたスケーリング方法)を元にした 設計解析&改善提案プログラム(Linter&Formatter) 及びアプリケーションFW(&ツールキット)からなる。
- 最重要テーマは 「関数型プログラミングによる既存のアーキテクチャの解体と再構築」、「(オート)スケーリング」
- フロントについては正直どう扱うべきかビジョンが見えてない(現在のNext.jsの議論についていけてないし、賛否両論あるため)、初期はAPIのみ?
設計解析&改善提案プログラム(Linter&Formatter) (仮称:Kaachan👩)
- 処理のパイプラインを意識した新たなアーキテクチャを前提に設計をアドバイス
- 既存のMVCフレームワークとやってる内容は変わらないが、ファイル/フォルダ名が大きく変わる)
- 後述しますが設計理論に弱いので全然固まってない😱
- 今のところ最初は1ファイルスタート、最初は処理順ベース/実装よりのネーミングで分割、スケーリング(例: route→validate→action→present)とし、そのあとクリーンアーキテクチャのように層ごとに切って制約したりしてスケーリングというイメージ。DBや外部アクセス層は早めに切りたいので同時並行になるかも。
- 既存のMVCフレームワークとやってる内容は変わらないが、ファイル/フォルダ名が大きく変わる)
-
コードがFatになってきたら検知し、自動でリファクタリング(ちゃんと決まれば強力だが過激すぎるのでオプション)
- ドメイン分割は流石に解析が厳しいので肥大化だけ指摘
- opinionatedにがんがん指摘し、オプション次第では整理してしまう挙動こそが「母ちゃん」たる所以
FW及びツールキット(仮称:Slime💧)
- Kaachanと設計解析&改善提案プログラム(Linter&Formatter)と連携して各種コマンドを提供
- (Kaachanによる強制リファクタリングオプションを有効してなかったり、ドメインによるコード分割したいユーザー向け)大量のフォルダのリネームや移動を行うマイグレーション機能が充実
- これがスライムたる所以
- (Kaachanによる強制リファクタリングオプションを有効してなかったり、ドメインによるコード分割したいユーザー向け)大量のフォルダのリネームや移動を行うマイグレーション機能が充実
-
汎用的な機能の実装が簡単に導入できる部分も強化
- 単なるユーザーと認証だけでなく、ユーザーを束ねるグループ概念を導入(オプション)
- 認可回りもroles/abiritiesを最初から用意して細かな権限管理対応(オプション)
- 新機能の有効無効を制御するFeatureフラグ機能(オプション)
- SSO対応(オプションながら主要Idpは公式サポート、プラグインでその他も対応)
- 通知周り強化(ロギングと同じノリで使えるレベルまで整備する)
- ログ周りも強化(JSON標準化等)
ターゲット層
- スモールスタートが確定していて、スムーズなアップスケーリングが必要
- Expressは薄い&古い、Honoも薄い&新しすぎ、Nest.jsは重厚長大&OOP前提でTSの本流から外れていて微妙に感じている
- LaravelでFatController or FatModelで苦しんでる~Serviceクラス導入以上の規模で自前でスケーリングさせないといけなくて設計考えるの色々しんどい、レールが欲しいと思っている
- 設計マニア
スケーリングについての対照表
アプリ規模はノリです。Don't think Feel it.
| アプリ規模 | Laravel界隈の状況 | Slime(仮称)の対応 |
|---|---|---|
| 1 | 公式対応してるが逆にリッチすぎ | 1ファイルで実行可 |
| 2 | 公式対応してるが逆にリッチすぎ | 公式対応(処理順ベース/実装よりのネーミングで分割) |
| 3 | 公式対応 | 公式対応(処理順ベース/実装よりのネーミングで分割) |
| 4-5 | ユーザーランドの知恵で対応(Serviceクラス導入) | 公式対応(処理順ベース/実装よりのネーミングで分割) |
| 6-7 | ユーザーランドの知恵で対応(UseCase/Actionクラス導入) | 公式対応(ここからCC参考に分割) |
| 8 | ユーザーランドの知恵で対応(部分的にCC取り込もうとして失敗したりする) | 公式対応(CC参考に分割) |
| 9-10 | 頑張ってクリーンアーキテクチャやる,Laravel捨てる,マイクロサービス化等 | 未対応(どうすべきなのか分からん……) |
大前提となる仮説
- 小~中規模のWebアプリケーションの設計については長年の知見でかなり煮詰まってきており、FWが一本のアップスケーリングのラインを規定してサポート(強要)することでDXが上昇する
- 大規模についても世に言われるほど「(同じコード規模で)プロダクトや仕様によって最適な設計が異なるので一般化できない」領域は少なく、意外とシェア食える(といいな……)
執筆者の背景
-
既存の設計理論に弱い(おい!)
- DDDやクリーンアーキテクチャ、レイヤードアーキテクチャはネットや人の話等で触りだけしか知らん
-
TS信者で関数型プログラミングによる、既存のOOPの影響を強く受けた設計論(ないし設計論を背景とした実装論)の解体・再構築に強い関心がある
-
倒産寸前の零細レガシーIT企業~ベンチャー~小企業(吸収合併)~中企業(親会社)と移ってきており、個人開発レベル~中規模(mpywさんの提唱する「なんちゃってクリーンアーキテクチャ」で何とかなるレベル)のWebアプリケーション開発に特化
- このためアップスケーリングについて考えさせられたり設計、実装する機会が滅茶苦茶多い
-
フルスタックエンジニア = Laravel経験は6年程度あって主要機能は触ってるので、不満や潜在需要は理解して言語化できるつもり
ここに至る全過程
ChatGPTのログ
途中、FWの命名ネタがちょっと長いですが、多分色々刺激受ける人多いんじゃないかなと思うので、よかったらどうぞ