国内企業向けシステムについての雑なノート

ここでいう「企業向けシステム」というのは、会計・人事・給与システムみたいな、「基幹システム」って言われるものとか、社内SNSのようなその他会社で使われるシステムのことです。 1年ちょっとはこういうシステムを開発していた身として、結局、どんなことに気を付けるのがいいのだろう？ということを考えてみたいなと。

インフラ

取り扱うデータがデータなので、少なくともテナントごとにデータベース分離はしたい。 コンピューティングリソースは、国内企業向けってことになるとまあ大体同じカレンダーに則って、平準化しないので、オートスケールする構成なるでしょう。 面倒なのでテナントごとにコンテナ分けてしまいたい。

データベース

クラウドベンダーの高いDB使わなくたって、SQLiteで良いのでは…という無根拠な直感があるのですがどうなんでしょ。 コンテナ化するなら PostgreSQLコンテナ みたいな方法があるんですけど、これとSQLiteだったらどっちが良いんだろうか。

アプリケーション

この用途なら別にSSOがどうのとか考えなくていいので、適当にMPA/SPAなサイトでいいんじゃないかな。

デザインチーム・フロントエンドチームってものを用意できるんなら React + Vite のSPA構成とかにすればいいし、 そうじゃないなら大人しくDjangoとかLaravelとか、任意のフルスタックフレームワークが用意してる　view の提供方法使えばいいと思うの。 API書く人が片手間でフロントエンドリポジトリでReactやらVueやら書きますで幸せになったことはない！

inertia.js みたいな、フルスタックフレームワークの中に自然にReactやらVueやら混ぜれますというのが 人数の少なめのプロジェクトにはちょうどいい塩梅なんじゃないかな…という予想。

マイクロサービス

これ以外に良い方法がないってわかってからやってください。

「論理的に異なるものだよね」って分類することは大事です。在庫・発注・注文・請求のように、おおまかにカテゴリ分けはできると思います。それは大事です。 だけど、実際に色々やる前にいきなり在庫サービス・発注サービス・注文サービス・請求サービスを作ってそれぞれAPI経由でやりとりしなきゃいけないだの、データベースが分離されてるだのはやりすぎです。

Microservices Are a Tax Your Startup Probably Can’t Afford が好きな記事です。

その他

何か色々踏み抜いてきて思ったこと。

• 大体バッチ処理でいい
  • 実行時間・実行件数・実行結果・エラーはちゃんとログを取ろうね
    • バッチスケジュールとちゃんと照らし合わしてね
• たまにはキューを使ったっていい
  • 何でもかんでもまとめてやらなくたっていいと思う。レコードごとに独立してできることなら裏でやればいい
• 遅いのはほとんどSQLクエリが悪い。
  • ORMは人類に早いので生SQLを書けばいいと思うの。JPAを捨ててMyBatis化するというプロジェクトをやったせいで変な学習をしてしまっています。 ↩
    • 上を万が一真に受けるのならSQLインジェクションには気をつけてね。
  • 実行計画はお友達
  • 「ページネーションのための総件数」をやるなら、豪華な検索を実現しないこと
    • 本当に10ページ目だの最終ページだのに行くと思いますか？
      • そんなことないなら総件数表示やめて、「次へ」とか無限スクロールくらいで誤魔化しましょう。
• タイムゾーンは本当に難しいのでできれば関わり合いにならないこと
  • 別に「イベント」だけ記録するなら問答無用でUTCとかでぶちこんどけばいいんですけどね…
  • 「未来の日付」ってのが入る時は気をつけてください。　
• 民法138条から143条は知っておきましょう（期間の計算の通則）

締め

自分が関わってきた苦しいことの振り返りみたいになりました。 ソフトウェア開発って大体過去に誰かが踏み抜いてきた失敗の繰り返しとすら言われていますから、少なくとも自分が関わった失敗は繰り返さないよう反省したいところ。

以上！