編輯出版分離

在過去一年左右與 Thoughtworks 專案團隊的對話中，一個經常出現的主題是內容管理系統 (CMS) 的影響力日益擴大。它們通常不被視為有幫助的，確實有明確的跡象表明它們正成為一種令人擔憂的侵入性工具 - 用於超出其核心目的的方式，以至於它們阻礙了整體開發。

在其他令人惱怒的事情中，一個常見的缺點是它們保留每一篇文章的一個副本[1]。這個單一副本在建立內容時會被編輯，並發布給讀者（通常在某種狀態變更標記上）。

保留某些資料的單一副本的想法很常見。這是正規化的關聯概念背後的基本原理，企業架構師通常會嘗試確保關鍵資料具有單一的權威副本。

然而，對於 CMS 來說，有一個明顯的缺點 - 編輯和發布的資料存取模式非常不同。編輯涉及少數人頻繁存取文章，進行讀取和更新。發布涉及更多人（我們希望）存取文章，但都進行讀取。有些編輯是為了修復已發布文章中的問題，但這些編輯遠少於讀取，而且來自一個受控良好的群組。

由於有這兩種不同的存取路徑，一些 CMS 保留文章的獨立副本，由相對獨立的模組控制。編輯模組圍繞頻繁更新進行設計，它提供編輯、追蹤變更和監控編輯流程工作流程的支援。當一篇文章發布時，它會複製到發布模組。

發布模組將文章視為主要為唯讀，很少更新，而且只會由編輯模組更新。因此，發布模組的設計圍繞向大量讀者提供該文章。至少這涉及資料儲存的不同配置。發布模組可以在叢集中的許多節點上自由複製，而編輯模組通常最好集中在單一節點上。對於不同的資料儲存技術也有爭議，允許每個模組使用適合其存取模式的東西。

文章也可以儲存在不同的格式中。通常文章會以一種形式編輯，但以另一種形式發布，例如以標記語言編輯並以 HTML 發布。在這種情況下，編輯模組應儲存標記語言形式，而發布模組則儲存 HTML。發布模組也可以對儲存的副本執行一些頁面組成工作。因此，如果您有靜態標頭，則可以在發布文章時將其新增到儲存的文章的 HTML 中，這樣可以節省每次閱讀時重新組成的功夫。[2]

分離這些模組也有助於編輯工作流程。通常，人們希望在發布到網路上之前預覽變更，由於您可以發布到暫存區域中的私人發布模組，因此透過分離很容易做到這一點。這可以很好地調整原本尷尬的邏輯，以找出從單一儲存中發布什麼。

使用者產生的內容確實為這種方法增加了一些皺紋。完全由使用者產生的 Wiki 將比經過策展的網站擁有更大且控制較差的編輯者群組。同樣地，讀者評論將來自更廣泛的寫作者。但即使有使用者產生的內容，您也應該獲得比寫作者多得多的讀者，因此將處理更新與提供已發布的頁面分開是有道理的。

使用支援編輯與發布分離的罕見系統的團隊發現它運作得很好，而大多數使用沒有這種樣式的工具的團隊認為這會改善事情。如果您正在評估 CMS，或為自己的需求建置一個 CMS，您肯定應該將編輯與發布分離視為要尋找的主要功能。