【EC開発体験記-Entity-】 自己完結したデータの集合

　Entityの設計はシステム設計の肝である。だが、構造をどうするかとか、外部参照や冗長をなくすとか、考えだすときりがないし、とにかく時間と労力がかかる。通常は、RDBのERモデル、オブジェクト志向のドメインモデルなどに則って設計することが多い。それぞれ設計ツールも豊富なので利用価値はある。しかし、概念や設計ツールの学習コスト、リレーショナルとオブジェクトの変換コスト、インピーダンスミスマッチは馬鹿にできない。そこで、ここは敢えて頭を空っぽにして、Entityの最低限必要な情報、すなわち、項目および属性とその構造だけに着目して、それらを洗い出すことから始めるとよい。とにかく、最初から難しく考えないで設計を進めていき、問題があればあとで修正する方法をとる。おすすめは、マインドマップの作成だ。（参考：テキストをマインドマップに変換するツール）　
　次に、自己完結した情報となるように項目を括る。とにかく外部参照のないものにするのがコツだ。例えば、カタログ巻末にあるFAX注文書は、受注に必要な情報がすべて記載されており、それだけで自己完結した情報となっている。システム化する際には、１枚の注文書が１インスタンスとなるように、さらには、1インスタンスが1レコードとなるように設計する。こうすれば、Entity＝Tableというイメージとなって都合がいい。そのことを、否定の２として挙げた。

否定の２
２．テーブルは第3正規形まで設計しない

　ここは正規化したい気持ちをぐっとこらえるのがポイントだ。また、Entityの階層を２階層とする一方、Tableの項目名をEntityと同一とする。このような規約で縛ることを、設定よりも規約（Convention over Configuration，CoC）という。こうすると、自由度は下がるが生産性は高まる。また、学習コストは少なく、インピーダンスミスマッチを解決できる。もしかしたら、「こんな設計ありえないだろ！」と正論をかざす頑固なRDBスペシャリストが出てくるかもしれないがスルーでよい。そもそも、設計にエネルギーと時間を使わないための規約なのだから、やらなくてもいい議論はやらない方がいい。ここは議論したい気持ちをぐっとこらえるのがポイントだ。

　話は戻り、ここで実際に、ECにおける「受注」について考えてみる。「受注」とは、「誰が何を注文して、いつどこに届けるか」という情報である。これを思いつくままに書くと、以下のようになる。

受注
　受注日時
　注文主
　　氏名
　　住所
　　電話番号
　　email
　　カード番号
　届け先
　　氏名
　　住所
　商品
　　JAN
　　売価
　お届け日時
　配送方法
　決済方法
　ステータス

以上が、とりあえずのEntity設計であるが、見ての通り、突っ込みどころ満載である。
まず、2階層といったくせに3階層になっている。（受注＞注文主＞氏名）このままではいかんので、規約に則って2階層に修正しなければならない（受注＞注文主氏名）
　それから、何気なく列挙している「ステータス」がある一方で、普通あるはずの「受注番号」などのキーがない。意味不明なものがあって、あるべきものがない、という中途半端なものになっている。また、１受注に複数の商品を購入される方もいるはずで、なんらかの「受注番号」で括る必要がある。さらに商品レコードを示すキーも必要になる。（商品レコードは一品一葉という概念で管理されている。これについては別の機会に説明したい）

　次にステータスを説明する。データが妥当（Valid）かどうかはステータスにより管理する。「ステータス」は、簡単にいうと、「受付られた」、「出荷された」等、データがどういう意味をもっているかということを示すためにある。いわゆる「判（ハンコ）」と同じものだ。
　まず、データがValidであれば、判を押された文書のように、それだけで意味を持つようになる。例えば、「ステータス＝受付」で、その商品が在庫にあり、指定した日に届けられる予定であることを意味し、「ステータス＝出荷」で、商品が出荷され、売上が計上されたことを意味する。

　また、判を押すためには、データの妥当（Valid）を判断するビジネスロジックが別途用意されなければならない。受注を受け付けるための条件は次の通りである。

１）注文主は実在するか
２）商品は存在するか
３）カードの与信はOKか
４）お届け日に配送できるか

　これらビジネスロジックは、サービスとして実装できるものばかりである。Entityを入力値としてサービスを実行し、データが妥当であればステータスを更新すればよい。これは、リソース志向に則った設計でもある。

　ビジネスロジックに関連して、プロジェクトでどうしてもやりたかったことで、否定の１、および１０がある。最後に、これについて説明したい。

１．受注番号等のキーを採番しない
１０．Web受注はブラウザからのプロバイダ通信だけで完結させる

　採番はシステムのあらゆる面でネックになるので、何とか頑張って無くしたかった。そのかわり、「誰がいつ注文したか」を示す、メアド＋受注日時(takezaki@mail.com-20081012010203012)をキーとした。そして、プロジェクトの第一フェーズまでは実際にこれで運用した。

しかし、これはやはり無謀であった。・・・動くものはなんとか作れたが、データ操作が非常に面倒くさくて、とても運用できるものではなかった。大反省（ ＞＜；した末、今では受注番号はキーとして必須であるという結論に至っている。
　採番はシステムのあらゆる面でネックになるといったが、特に心配だったのはスケーラビリティへの影響である。これは採番プロバイダとしてサービス化することでなんとか解決できたと思う。現在の採番プロバイダは受注番号以外にも配送伝票番号や生産番号などのキーを複数発行している。
　また、プロバイダ通信だけで完結させるという案１０は、採番プロバイダの例のように作ることで有効であるように思えた。実際にECシステムでは、商品マスタや受注機能のプロバイダ化ができており、AJAX（JavaScriptによるプロバイダ通信）を駆使すれば、ブラウザとプロバイダだけでECサイトが作れると思った。しかし、セキュリティとSEOの２つの理由で断念せざるを得なかった。まず、カードオーソリのために外部サービスを呼ぶ必要があり、これをクライアントのJavaScriptだけで実行することは不可能であったこと。それから、SEOにおいては、HTMLを出力できることが重要で、どうしても中間にXMLからHTMLを生成させるPHPを介在させる必要があった。
　このように、あまり面白くない結果になってしまったこのECサイトであるが、実はPHPから商品プロバイダや受注プロバイダを呼んでいるし、カート（Flex2）からも同様にプロバイダを呼んでいる。にもかかわらず、外部から見ると普通にDBを検索しているように見えてしまう。まあ、サービス志向でWeb2.0サイトであることを醸し出せないのはちょっと残念ではあるが、それなりに意味のある設計だとは思っている。
これからも無謀と思わずいろいろトライしていきたい。