編集と公開の分離

昨年からThoughtworksのプロジェクトチームとの会話の中で、コンテンツ管理システム（CMS）の影響力の増大が繰り返し話題になっています。CMSは通常、役に立つものとは見なされていません。実際、CMSが懸念されるほど侵略的なツールになりつつあり、本来の目的を超えて使用され、開発全体を阻害しているという明確な兆候があります。

他の煩わしさの中でも、一般的な欠点は、記事[1]のコピーを1つだけ保持することです。この単一のコピーは、コンテンツ作成の一部として編集され、読者に公開されます（通常、状態変更フラグによって）。

データの一部を1つのコピーだけ保持するという考え方は一般的です。これは、リレーショナル概念の正規化の根底にある原則であり、エンタープライズアーキテクトは、重要なデータに単一の信頼できるコピーがあることを保証しようとすることがよくあります。

しかし、CMSには明確な欠点があります。編集と公開のデータアクセスパターンが大きく異なることです。編集には、少人数が記事に頻繁にアクセスし、読み取りと更新の両方を行います。公開には、より多くの人々（そう願っています）が記事にアクセスしますが、すべて読み取りを行います。公開された記事の問題を修正するために行われる編集もありますが、これらは読み取りよりもはるかに少なく、統制されたグループの人々によって行われます。

このように異なる2つのアクセスパスがあるため、一部のCMSは、比較的独立したモジュールによって制御される記事のコピーを個別に保持しています。編集モジュールは、頻繁な更新に対応しており、編集、変更の追跡、編集プロセスのワークフローの監視をサポートします。記事が公開されると、公開モジュールにコピーされます。

公開モジュールは、記事をほとんど読み取り専用として扱い、更新はまれに、編集モジュールによってのみ行われます。そのため、公開モジュールは、多数の読者にその記事を提供するように設計されています。少なくとも、これにはデータストレージの異なる構成が必要です。公開モジュールは、クラスタ内の多くのノードに自由に複製できますが、編集モジュールは通常、単一のノードに集中させる方が適切です。また、異なるデータストレージテクノロジーを使用することで、各モジュールがそのアクセスパターンに適したものを利用できるという議論もあります。

記事は異なる形式で保存することもできます。多くの場合、記事は1つの形式で編集され、別の形式で公開されます。たとえば、Markdownで編集し、HTMLで公開します。この場合、編集モジュールはMarkdown形式を保存し、公開モジュールはHTMLを保存する必要があります。公開モジュールは、保存されたコピーに対してページ構成作業を行うこともできます。静的なヘッダーがある場合、記事が公開されるときに、保存された記事のHTMLに追加できます。これにより、読み取りごとに再構成する手間が省けます。[2]

これらのモジュールを分離すると、編集ワークフローにも役立ちます。多くの場合、公開前に変更をプレビューしたいと考えています。これは、ステージングエリアのプライベート公開モジュールに公開できるため、分離することで簡単に実現できます。これは、単一のストレージから何を公開するかを判断するための、そうでなければ厄介なロジックをうまく回避できます。

ユーザー生成コンテンツは、このアプローチに多少のしわを寄せます。完全にユーザー生成のWikiは、キュレーションされたサイトよりも、より大きく、統制のされていない編集者グループを持つことになります。同様に、読者のコメントは、より幅広いライターから寄せられます。しかし、ユーザー生成コンテンツであっても、ライターよりも読者の方がはるかに多いため、更新の処理と公開されたページの提供を分離することは理にかなっています。

編集と公開の分離をサポートするまれなシステムを使用しているチームは、それが非常にうまく機能していることを発見しており、このスタイルを持たないツールを使用しているほとんどのチームは、それが物事を改善すると考えています。CMSを評価する場合、または独自のニーズに合わせてCMSを構築する場合は、編集と公開の分離を重要な機能として検討する必要があります。