区分値設計 再考 | フューチャー技術ブログ
雑感：区分値設計にVOの視点を重ねてみる ～Future記事が教えてくれたこと～
システムを作っていると、「区分値」って当たり前のように出てきますよね。「ステータス」なら「下書き」「レビュー中」「承認済み」とか。コード上では 01, 02, 03 だったり、draft, in_review, approved だったり。
これって、単なる識別ラベルに見えがちで、設計で深く悩むポイントじゃないと思われるかもしれません。でも、本当にそうでしょうか？
私は普段から、これらの区分値は単なるデータじゃなくて、その値特有のルールや振る舞いを持つ「バリューオブジェクト(VO)」として捉えるべきじゃないか、と考えています。そうすることで、区分値自体が意味を持ち始めて、コードがもっと分かりやすく、そして堅牢になるはずだと。
そんなことを考えていたら、Future Architect社のブログ記事「区分値の設計についての考察」が目に留まりました。この記事が、まさに区分値の表現方法（シンボル値 vs セマンティック値）や管理方法を深く掘り下げていて、「そうそう、そこ大事だよね！」と首がもげそうになりました。 今回は、この記事を読みながら、VOという自分の視点と重ね合わせることで見えてきたこと、考えたことを雑感としてまとめてみようと思います。
やっぱり「セマンティック値」はVOと相性が良い
記事では、01 のような「シンボル値」より、draft のような「セマンティック値」を推奨しています。これはVOの考え方とすごくしっくりきます。
VOって、値そのものがドメインの意味を表すことを大事にしますよね。セマンティック値は、まさにそのドメイン概念をコード上で直接表現しています。order.status == OrderStatus.APPROVED みたいに書ければ、"03" って何だっけ？とコメントを探す必要もなく、コードが意図を語り始めてくれます。これぞVOが目指したい世界の一つだと感じます。
VOの居場所は「ソースコード」の中
記事が、区分値の定義場所としてDBマスタではなく「ソースコード（列挙型や定数）」を推奨している点も、VOの観点からは自然な流れです。
VOはただの値じゃなく、「承認済みからは下書きに戻せない」みたいなルール（振る舞い）も持ちます。こういうロジックを実装するには、やっぱりソースコード上のクラスや列挙型が必要です。DBマスタだと、区分値はただのデータになってしまい、振る舞いを持たせられません。IDEの補完や型チェック、テストのしやすさといった開発体験の向上も、ソースコードで定義するからこそのメリットでしょう。
「命名コスト」はVO設計の核心を突いている
セマンティック値の課題として挙げられている「命名コスト」。これ、まさにDDDでいう「ユビキタス言語」を探す苦労と同じですよね。
VOとして区分値を設計するなら、その名前はビジネスと開発者が共通認識を持てる言葉でなければなりません。分かりやすい名前がすぐに見つからないドメインもありますが、そこで安易な名前に逃げず、チームで議論し、ドメインの本質を表す言葉を探し当てる。このプロセスこそが、VOの価値を高め、ドメイン理解を深める重要な活動なんだと、改めて思いました。
区分値の管理場所とVOの「関心事の分離」
記事では区分値の管理場所についても触れ、「表示名」のようなUI固有の情報はクライアント、「ロジック」に関わる情報はサーバ、といった「分離管理」を推奨しています。
これもVOの責務範囲を考える上で示唆に富んでいます。VOはドメイン層の住人であり、ビジネスルールに責任を持ちます。画面での「表示順」とかはVOの知ったこっちゃない。これはUI層の関心事です。ドメイン（VO）とUIの関心事をきちんと分ける。これはクリーンな設計の基本ですよね。
フラグという名の「状態」 – boolean で思考停止しない
最後に触れられていた「フラグ」の話も興味深かったです。「本当に2値で完結する？」という問いかけ。これはVOの考え方にも通じます。
安易に boolean でフラグを表現すると、その裏にあるビジネス上の意味合いや将来の変化が見えにくくなりがちです。isEnabled という boolean より、ActivationStatus というVOを作り、ACTIVE, INACTIVE といった状態を定義する。そうすれば、将来 SUSPENDED（一時停止）みたいな状態が増えても、boolean をいじるよりずっと自然に対応できるはずです。
おわりに
Future Architect社の記事は、区分値という日常的なテーマを通じて、ソフトウェア設計の奥深さを改めて気づかせてくれました。特に、私が普段から考えているVOの有効性や、なぜVOとして設計するのかという「必然性」を、具体的な比較やトレードオフを示しながら補強してくれたように感じます。
「今までこうだったから」で思考停止せず、なぜその設計を選ぶのか、それが将来どう影響するのかを問い続ける。区分値一つにも、そんな設計への向き合い方が大切なんだなと、改めて考えさせられました。