Use Object-Oriented UI (OOUI) for Component Architecture

コンテキスト

フロントエンド開発において、コンポーネント設計の一貫性と保守性を向上させる必要がある。特に、ビジネスロジックとUIコンポーネントの関係性を明確にし、開発者が直感的に理解できる命名規則とコンポーネント構造を確立することが重要である。

現在、多くのプロジェクトでコンポーネントの命名規則が統一されておらず、同じ機能を持つコンポーネントでもプロジェクトやチームによって異なる名前付けがされることがある。これにより、コードの可読性が低下し、新しいメンバーのオンボーディングに時間がかかる問題が発生している。

決定事項

OOUI（Object-Oriented User Interface）の考え方をコンポーネント分割の基本哲学として採用する。具体的には次のようなルールを適用する。

1. モデルベースの命名規則: ビジネスモデル（User、Product、Orderなど）をコンポーネント名のプレフィックスとして使用する

   • 例: UserForm、UserList、UserDetail、UserCard
   • 例: ProductList、ProductDetail、ProductSearch

2. オブジェクトファースト: UIコンポーネントは、まずビジネスオブジェクトを中心に考え、その後にアクションを考慮する

3. 一貫性のある構造: 同じモデルに関連するコンポーネントは、同じディレクトリ構造に配置する

選択肢

選択肢1: OOUI (Object-Oriented UI)

• 利点:

  • ビジネスロジックとUIの関係が明確になる
  • 命名規則が一貫し、予測可能になる
  • モデルベースで考えることで、ドメイン知識がコードに反映される
  • 新規メンバーがコンポーネントの目的を理解しやすい
  • リファクタリング時にモデルの変更に追従しやすい

• 欠点:

  • 既存のプロジェクトでは大規模な命名変更が必要になる可能性がある
  • 共通UIコンポーネント（Button、Modalなど）には適用しづらい
  • 複数のモデルにまたがるコンポーネントの命名が難しい

選択肢2: 機能ベースの命名（従来型）

• 利点:

  • 汎用的なコンポーネントが作りやすい
  • UIライブラリの慣習に従いやすい
  • 小規模なプロジェクトでは十分な場合が多い

• 欠点:

  • ビジネスロジックとの関連性が不明確である
  • 同じ機能でも開発者によって異なる名前になりやすい
  • プロジェクトが大規模化すると命名の一貫性が失われやすい

選択肢3: Atomic Design

• 利点:

  • UIの階層構造が明確になる
  • デザインシステムとの親和性が高い
  • 再利用性を重視した設計が可能である

• 欠点:

  • ビジネスロジックとの関連性が薄い
  • 分類の判断が主観的になりやすい
  • 学習コストが高い

結果

この決定による影響を以下に記述する。

• ポジティブな影響:

  • コンポーネントの目的と責任範囲が明確になる
  • チーム内でのコミュニケーションが円滑になる
  • コードレビューでの議論が減少する
  • ビジネス要件とコードの対応関係が追跡しやすくなる
  • テストケースの作成が容易になる

• ネガティブな影響:

  • 既存プロジェクトでの移行コストが発生する
  • 汎用UIコンポーネントとの使い分けが必要となる
  • 初期の学習コストがかかる

• リスク:

  • モデルの粒度が適切でない場合、コンポーネントが肥大化する可能性がある
  • ドメインモデルが頻繁に変更される場合、リファクタリングコストが高くなる
  • チーム内でOOUIの理解度に差がある場合、実装にばらつきが生じる

参考資料

• Object-Oriented User Interface Design
• OOUIの基本的な考え方
• コンポーネント設計のベストプラクティス