はじめに

最近、アプリ開発の中で「ワイヤーフレーム」を使い始めたところ、思いがけずドメイン設計が大きく前進しました。

ワイヤーフレームとは、 Figma などを使って作る UI デザインの一種です。
ただし、色やフォントサイズなどの細かい UI にはこだわりません。
ボタンや入力欄であることがわかれば良いという程度のラフな UI デザインのことを言います。

もともとドメイン駆動で設計を進めていたのですが、どうしても「抜け」や「曖昧さ」が残る感覚があり、手応えが弱い状態が続いていました。

しかし、ワイヤーフレームを作り始めたことで、その状況が一変しました。

この記事では、 ワイヤーフレームがどのようにドメイン設計を補完し、加速させたのかを整理してみます。

ドメイン設計だけでは埋まらない違和感

ドメイン設計を進めていると、以下のような状態に陥ることがありました。

  • ユースケースはある程度整理されている
  • エンティティや値オブジェクトも定義できている
  • しかし「本当にこれで使えるのか？」という違和感がある

つまり、構造はあるが、実感がない状態です。

このとき不足していたのは、「ユーザーがどう操作するか」という視点でした。

ワイヤーフレームを作って起きた変化

試しにワイヤーフレームを作り始めたところ、明確な変化がありました。

1. ユーザーの行動が具体化される

ワイヤーフレームでは「画面上で何をするか」を考える必要があります。

  • どこで入力するのか
  • どの順番で操作するのか
  • 何を確定とみなすのか

これにより、ユースケースが単なる文章ではなく、操作として具体化されました。

2. 必要なデータと制約が見えてくる

操作を具体的にすると、自然と以下が見えてきます。

  • この画面では何のデータが必要か
  • この操作はどんな条件で許されるのか

ここで重要なのが、 不変条件（インバリアント） です。

例えば、口座振替管理アプリなら、

  • 支払い元は必ず 1 つである
  • 振替は「元 → 先」の関係を持つ
  • 不正な組み合わせは作れない

など、これらはドメイン設計だけでも定義できますが、 ワイヤーフレーム上で「操作」として考えることで、一気に現実味を帯びます。

3. ドメイン設計の「抜け」が露出する

ワイヤーフレームを作る中で、次のような気づきが頻発しました。

  • この状態、どうやって作る？
  • この操作、どのユースケースに対応する？
  • このデータ、どこに属する？

つまり、ドメイン設計で曖昧だった部分が強制的に表に出てくるのです。

これはかなり大きなメリットでした。

ワイヤーフレームは見た目のためではない

今回一番の発見はここです。

ワイヤーフレームは、

  • UIの見た目を決めるためのものではなく
  • 制約と構造を発見するためのツール

でした。

ワイヤーフレームを通すことで、

  • UI からドメインが洗練され
  • ドメインが洗練されることで、さらに UI が洗練される

という相乗効果が得られます。

作業を進めるたびに「UI とドメインがつながる」感覚があります。

この「つながる感覚」は、設計がうまくいっているサインだと感じています。

まとめ

ワイヤーフレームを取り入れたことで、以下の効果がありました。

  • ユースケースが操作として具体化される
  • 不変条件が自然に見えてくる
  • ドメイン設計の抜けが露出する
  • 設計全体に一貫性が生まれる

結果として、 UI設計とドメイン設計が分離されたものではなく、相互に補完し合って、プロダクトが良くなっていく と実感しました。

おわりに

もしドメイン設計を進めていて、

  • なんとなく手応えが弱い
  • 抜けがある気がする

と感じている場合は、 一度ワイヤーフレームを作ってみることをおすすめします。

見た目を整える必要はありません。 むしろラフであるほど、本質が見えてきます。

設計が「つながる」感覚を得られるはずです。