フレームワークの下層を設計するという発想：業務システム開発における「ドメイン内UI抽象化」の戦略
はじめに：フレームワーク選定だけでは差別化できない時代
近年のシステム開発プロジェクトでは、ReactやVue、Next.js、Nuxtといったフロントエンドフレームワークや、Laravel、Django、NestJSといったバックエンドフレームワークが多くのプロジェクトで定着しています。一方、これらのフレームワーク選定そのものがプロジェクトの成功要因ではなくなりつつあり、「その上でどのような実装思想を採用するか」がより重要視されています。
特に、Web開発会社や受託開発会社においては、表層のフレームワークに依存しない、より内側の”開発思想”や”構成戦略”がプロジェクト品質の鍵を握る場面が増えています。
本記事では、「フレームワークの“さらに下”にある、業務ドメインとUIの橋渡しレイヤー」をどう設計するか、つまり「ドメインUI抽象レイヤー」の戦略設計について解説します。
なぜ「ドメインUI抽象レイヤー」が必要なのか
ドメインモデルとUIのギャップを埋める層がないと何が起きるか
業務システム開発において、ドメインモデル（業務ロジックを表現したコード）とUIは密接に関係します。しかし、多くのプロジェクトでは、次のような問題が発生します：
・UIの変更がドメインモデルへ無理やり影響を及ぼしてしまう ・業務ルールの変更がUIと結びつきすぎて分離不能になる ・UIコンポーネントが業務用語に汚染されて再利用できない
このような状態は、初期リリースには間に合ったとしても、継続運用や複数システム展開時に大きな障害になります。
フレームワークが想定していない「業務に最適化されたUI層」
ほとんどのフレームワークは、データの表示・更新という観点では強力な機能を提供しています。しかし、以下のような「業務文脈に紐づいたUI構成」までは面倒を見てくれません：
・役職や部署に応じて可変する操作項目 ・時間帯や状態によって切り替わる業務ボタン ・複数画面に跨る入力ステップの業務定義連携
こうしたニーズに応えるには、「ドメインの構造とUIの構造を仲介するレイヤー」の実装が不可欠です。
「ドメインUI抽象レイヤー」の設計アプローチ
1. UIとドメインの責務を分離するルールを決める
まず重要なのは、「どこまでがUIの責任で、どこからが業務ドメインの責任か」を明示することです。以下のような分離が有効です：
・ドメイン層：データの意味と処理 ・UI抽象層：ドメインをUIに変換する表現 ・UI層：React/Vueコンポーネントなど
このように3層構造を採用することで、UI側では抽象的な構造（例：「表示項目」「選択肢」「表示可否」）だけを扱い、ドメイン層の構造変化から隔離できます。
2. UI構成情報をコード化する（UI DSLの導入）
「この画面では、Aという状態のときにBという選択肢を表示する」といったUI構成ルールを、設定ファイル（YAML/JSON）や型付きクラスとして構成定義ファイルに切り出すことで、UI変更の影響を最小化できます。
例：
{
"field": "出勤区分",
"type": "select",
"options": ["通常出勤", "時差出勤", "直行", "直帰"],
"visibleIf": "user.role == 'fieldStaff'"
}これにより、UI構成自体が「業務ルールを表現するドキュメント」となり、非エンジニアとも仕様を共有しやすくなります。
3. 業務ルールの変更に強い型定義とUIマッピングの活用
TypeScriptやZodなどの型システムを活用し、業務データとUI構造の整合性を強く担保することも有効です。
たとえば、申請ステータスに応じた入力制御を行う際：
type ApplicationStatus = 'draft' | 'submitted' | 'approved';
interface FormConfig {
status: ApplicationStatus;
editableFields: string[];
}これを元に、ドメイン層からUI層に「どのフィールドが編集可能か」という構成情報を渡すことで、ロジックの二重実装を防げます。
実際の導入例と開発現場の反応
フィールドスタッフ向けアプリにおける活用
現場作業員向けのモバイル業務アプリにおいて、ロール別に表示項目や操作ボタンが変わる複雑なUIが課題となっていました。
ドメインUI抽象レイヤーを導入し、以下のような構成を採用しました：
・操作項目の可視性をロール別定義ファイルで管理 ・UI構成をJSONとして定義 → アプリはそれを読み取って画面構成を自動化 ・業務フローの変化時にはJSONの差分管理のみで対応可能に
この結果、プロジェクトチームからは「フロント改修が大幅に軽減された」「業務フローが変わっても現場で即対応できる」といった評価を得られました。
保守・拡張フェーズにおける効果と今後の展望
構成ファイル主導のUI抽象レイヤーを導入したことで、以下のような保守運用上のメリットが実現しました：
・UI変更時の差分レビューが明確になり、改修が早く正確に ・複数環境（拠点・業態・契約別）のUI分岐が統一的に管理可能 ・ドキュメントとしての構成定義が仕様書の役割も果たす
今後は、UI DSL（Domain Specific Language）をさらに強化し、業務担当者がGUIエディタで直接UI設計を行える「ノーコード構成管理」の方向にも応用が可能です。
まとめ：フレームワークの“下”にこそ戦略を
UIはフレームワークで描く時代から、「業務を表現する構成情報を描画する」時代へと進化しています。受託開発においては、「どのフレームワークを使うか」ではなく、「その下にどのようなUI設計レイヤーを設けるか」によって、拡張性・保守性・業務理解度が大きく変わってきます。
今後も業務システム開発においては、「業務ロジックをUIに落とし込む設計力」こそが、開発会社としての差別化につながるでしょう。
