メインコンテンツまでスキップ

開発の背景と設計思想

このページは、Nijo が「なぜこういう作りになっているのか」を補足するための文書です。 導入判断や日常的な利用に必須の情報ではありませんが、設計思想や適用対象を把握したい場合に参照してください。

このソフトウェアを作成した動機​

筆者は主にエンタープライズ寄りの業務アプリケーションのスクラッチ開発に携わってきました。 業種は主に製造業、サービス業が中心です。 システムの役割としては、販売管理・在庫管理・生産管理・勤怠管理・請求管理あたりが該当します。 アプリケーションの形態は、パッケージではなくスクラッチ開発です。

そういった中で、以下のようなニーズを感じていました。

画面からDBまでを一気通貫でカバーしてくれるちょうどよいライブラリ・フレームワークが欲しかった​

  • Entity Framework CoreはDBアクセス層として非常に優秀であり、.NETのエコシステム全体で広く使われていますが、EF Core単体では画面からDBまでを一気通貫でカバーすることはできません。
  • HTML, CSS, JavaScript を中心としたエコシステムは UI/UX を実現するうえで非常に強力であるが、データの完全性や整合性を保ったり、多数のユーザーが同じリソースを同時に更新する際の考慮をしたりといったバックエンドの歴史は弱いです。

しかし、それぞれのエコシステムはそれぞれ毎の世界に閉じており、両者をつなぐ部分は手作業で実装しなければなりません。とはいえ、そのつなぎの部分は、単純作業でありながらもミスが起きやすく、かつミスが起きた場合のシステム全体に及ぼす影響が大きいです。

そこで、ここを「Nijoのスキーマ定義による画面からDBまでの一気通貫した構造定義」と「静的型付け言語の厳密な型チェック」でカバーすることで、開発効率と品質の両立を実現したいと考えていました。

CRUD機能のうちCUDは自動生成する効果が大きい​

  • データの形が違うだけで気を付けなければいけないポイントはだいたいいつも同じです（キー重複の考慮、同時編集や排他制御、更新データ中に配列がある場合の実装の大変さ、二重登録の考慮、トランザクションの切り方、など）。
  • その割には品質が低い場合のシステム全体に及ぼす実害が、参照系処理に比べてとても大きいです。

開発者同士で、具体的に動くデータを中心とした、地に足のついた議論ができるようにしたかった​

システム全体のデータ設計において、開発チーム内でデータモデルの議論を軸にして検討を進めたいことがよくあります。そこではメンバー間で実際に動くデータを見つつ認識共有しながら進まないと議論が空中戦になるのですが、そのためにはデータモデルのたたき台を考えてから実際に動くデータができるまでを数分程度で実現できるツールが必要でした。

スクラッチ開発の柔軟性は捨てたくない​

上記のような要件を満たしつつ、通常のスクラッチ開発と同レベルの柔軟性をもったツールが欲しいと思っていました。

  • ネストされた子要素、伝票の明細など子要素の配列、多態性をもった子要素、他のデータへの参照、といった複雑なデータ構造を定義できてほしい
  • 複雑なデータについてパフォーマンスを落とさず高速なクエリを発行するためにはCQRSや生SQLの実装ができるようになっていてほしい。そのため、Nijoは一覧検索処理のSQLで言うところのWHERE, SKIP, TAKE, ORDER BY 句を自動生成するにとどめ、FROM, SELECT 句で実現する複雑な結合や集計、サブクエリなどは開発者に任せる形をとっています。
  • 日次業務のオペレーションに耐えうる画面、現行の業務フローに合致した画面、など厳しい要件を満たすためにはUIのソースをゼロから組み上げられるようになっていてほしい。そのため、NijoはUIが呼び出すAPIの窓口の関数までを自動生成するにとどめ、UIの実装は開発者に任せる形をとっています。

いつでも捨てられる状態がほしかった​

  • いわゆるエンタープライズ系システム・基幹寄りのシステムは、一度構築すると数年単位で使い続けるのが通常であり、寿命が長いのでフルマネージドであっておきたい需要が高い
  • ここで、Nijoという特定のツールに詳しい開発者が数年にわたり社内に在籍し続ける保証はない
  • そのため、Nijoで生成されたソースコードは、純粋な C#, TypeScript コードとし、Nijoのランタイムに依存しない形をとっています。運用担当者は、Nijoを使ったスピーディな開発を続けることもできますし、Nijoを捨てて純粋なスクラッチ開発に切り替えることもできます。