先日DrupalのStorage Entitiesモジュールを試してみたを書いたこともあり、もう一度Drupalの基本構造を理解したいと思って、UMLで理解を書き上げてみたのが冒頭の画像である。
この図でVocabularyとあるのが、タクソノミー・タームでContent Type(Node)と双璧をなしている。歴史的な経緯を深く知っているわけではないが、Nodeは記事あるいはブログを書くために生まれ、タクソノミー・タームはタグ付けするために生まれたと考えている。Comment Typeは返信を管理するために生まれ、ブロックは表示上だけに必要でContentとして管理する必要のない要素を書くために導入された可能性が高い。
Drupal8あるいはDrupal9でDrupal7時代にある種決別し、もう一度本質的にどういう構造であるべきなのかを再考してEntityとFieldで整理し直されることになった。一方のFieldは以下のように定義されている。
FieldはDrupalの世界のデータ型を表している。この中で極めて特徴的なのが、Entity referenceだ。Drupal 8でViewsがCoreに含まれるようになったことで、Entity referenceもDrupalの世界で中心的なデータ型になった。
Contentを定義する時に他のNodeを参照するFieldもタクソノミー・タームを参照するFieldもEntity referenceとなる。VocabularyのFieldにもEntity referenceを定義でき、他のタクソノミー・タームでもNodeでも参照可能となる。
ここで、疑問が湧く。ではタクソノミー・タームとNodeは本質的に何が違うのか。どちらもEntityであり、同じ対象をVocabularyとしてモデル化することもContent typeとしてモデル化することも可能である。付随するメソッドの違いでどちらを使うべきか選択するという考え方も取れるので、私は多くのケースで、マスター形のデータはタクソノミー・タームとして定義してきた。しかし、マスターデータは、Content typeが正規化されていれば、対象データに対して1つだけ定義するのが原則となる。だから、タグ付けとは意味が異なるので、Content typeで定義するほうが好ましいと感じるケースは少なくない。一方で、マスターデータはブログ記事のようなContentかと問うと、違和感を感じる。相対的な意味ではContentなのだが、東京都のコードは13であるなどというマスターデータは裏方であって、13というコードは本来ユーザーから見える必要もなければ意識させる必要もない。
タグ付はタクソノミー・タームから見ると正規化して表現できるのだが、Content作者から考えるとタクソノミー・タームは自分の管理下にないので、タクソノミーターム側に定義としてContentに結びつける関係を定義するのは変で、Content側から勝手にタグ付けする方がずっと自然になる。だから、タグのフィールドは多くの場合複数オカレンスを許す形になる。言い換えれば、Content typeの定義は正規化を守らなくて良くなる。さらに踏み込めば、Content typeでタグ付を許すと、一つの入力でContentの本質部分と、複数のタームとContentの関係を一気に定義することになっている。Content作者から見れば合理的な構造になっているのである。
実際、工夫すればContent typeを上手に使い回せば、Vocabularyは一切使わなくても同様なサイトを作成できるだろう。さらに踏み込めば、Storage entityを使えば、Content typeもVocabularyも派生クラスとして実装することが可能になる。
Drupal 10では、まだその時期は来ないだろうが、やがてリファクタリングが行われ、容易にコンテンツが移行できる形でEntityのモデル、Fieldeのモデルがシンプルに定義され直すだろう。その時期が来れば、今よりわかりやすいCMSになるし、本質的にデジタルコンテンツ・マネジメントプラットホームとなっていくのだと考えている。
実装にPHPが用いられていることで馬鹿にされることも少なくないが、私はDrupalは合理的な進化の途を歩んでいると思う。