フルスタック
画面からデータベースまでを対象範囲にしつつ、一覧検索のような定型処理を自動生成して、業務固有の表現だけを個別実装に残せます。
Scope
何を自動化し、何を開発者に残すかが明確です。
Nijoは「何でも自動化する」ツールではありません。スキーマから一意に決まる部分を強く自動化し、 業務価値が出る部分は通常のスクラッチ開発と同じ自由度で残します。
設計の中心はスキーマ定義
画面項目、データ構造、参照関係、更新単位をスキーマとして定義し、関係者が同じ絵を見ながら議論できます。 この可視化は、あとから陳腐化する資料ではなく、コード生成と同期された開発中の設計図として機能します。
開発者は主にこのGUIを操作して、データ構造や関係性を定義します。
対象範囲は画面からDBまで
Nijoは、Webクライアント、サーバー、データベースまでをひと続きの構造として扱います。 一覧検索処理のような定型ロジックは自動生成できますが、検索条件や検索結果を画面上でどう表現するかは、 通常のJavaScriptやTypeScriptによる開発で自由に決められます。
自動生成は下支えに徹し、エンドユーザー向けUIは案件に合わせて作り込めます。
Boundary
自動生成と個別実装の境界が読み取りやすい構造です。
更新系の処理では、共通で守るべき品質と、案件ごとに変わる業務判断を分けて扱うことが重要です。 Nijoはその境界をコード上にも明示します。
画像左側: 開発者が自身で実装する部分
- ※1 在庫引当のような業務固有ロジック（在庫引当: 小売店などで売上確定時に在庫データのうちどれをその売上と紐づけるかのロジックのこと）
- ※2 更新前の確認メッセージを出すタイミングや文言
- ※3 トランザクションの境界。（画像中には無いが、UI表現、認証認可、外部システム連携なども個別実装）
画像右側: 自動生成された部分
- ※4 楽観排他のバージョンや登録日時・登録者など監査用属性の設定
- ※5 必須、MaxLength、桁数、型といったデータ構造から自明に導ける入力チェック
矢印: 手動実装部分で自動生成処理を呼び出している箇所
Type Safety
TypeScriptとC#の構造体が自動的に同期されます。
サーバー側はC#、クライアント側はTypeScriptで厳密に型定義されたデータクラスを生成します。 同じスキーマ定義から両方を生成するため、言語を跨いだデータ構造の整合性を維持しやすくなります。 データベースとアプリケーションの型同期は Entity Framework Core の標準的な仕組みに乗ります。
画像左: TypeScript , 画像右: C#
Sales Points
このツールが解決しようとしている問題
画面、API、型定義、DB設計、チーム内の認識合わせが分断されると、単純作業が増え、変更に弱くなります。 Nijoはその接続部分をスキーマと生成コードで受け持ちます。
型安全
C# と TypeScript の型定義を同じスキーマから生成し、Entity Framework Core まで含めてデータ構造の同期を保ちます。
設計共有
スキーマ定義をGUIで可視化し、複雑なリレーションや機能分割を関係者と俯瞰しながら議論できます。
業務システム向け
排他制御、論理削除、監査用属性、ログマスキングのような基幹系で問題になりやすい論点を自然に組み込むことができます。
スクラッチ並みの柔軟性
UI、認証認可、外部連携、複雑な業務ロジックは通常の C# と TypeScript で自由に作り込めます。
Constraints
重要な制約を先に明示します。
採用前に判断しやすいように、必須となる技術と、Nijoがカバーしない責務をトップページでも明示します。
利用必須
- C# / .NET
- Entity Framework Core
利用推奨
- ASP.NET Core
- TypeScript
別途設計が必要
- 認証・認可
- UIコンポーネントの具体的な挙動
- 外部システム連携や横断的な運用要件