私のコメントを残した後、これに答えようとすることにしました:)
「アセット」の定義が「ノード」(Drupal など) またはドキュメント (MongoDB や CouchDB の JSON スタイル ドキュメントなど) に沿っている場合、次のような情報があります。
この記事では「ノード」という用語を使用します。「資産」に最も近く、より一般的に使用されていると思います。これも非常に抽象的な答えかもしれませんが、少なくとも考えさせられ、正しい方向に向けられることを願っています.
ノードベースのアーキテクチャは、ニューラル ネットワーキング パターンとオブジェクト指向プログラミングのクロスとして説明できます。重要なのは、「ノード」はデータのポイントであり、ノードは何らかの方法で相互に接続できるということです。
一部のアーキテクチャでは、ノードをオブジェクト指向クラスのように扱います。このクラスでは、親ノードのさまざまな特性を継承できるノードのさまざまなクラスがあります。すべてのタイプのノードは、その親の基本的なプロパティを継承します。「エッセイ」ノードは、のプロパティを継承する場合があります。ベースノードのプロパティを継承する「Text-Document」ノード。Drupal はこの継承モデルをうまく実装していますが、Facebook の GraphAPI/Open Graph Protocol のような方法でノード間の接続を強調していません。
ノードベースのアーキテクチャのこのパターンは、任意のレベルでも実装でき、自然界に存在します。社会やエコシステム内の社交界を考えてみてください ;) ソフトウェア エンジニアリング レベルでは、MongoDB の単純な方法など、データベースの形をとることができます。データのノード (その場合はドキュメントと呼ばれます) があります。これらのドキュメントは他のドキュメントを参照できますが、Drupal と同様に、Mongo は接続性を強調しません。皮肉なことに、ドキュメント ベースのデータベースとは対照的な MySQL のようなリレーショナル データベースは、実際には接続性をより重視していますが、それについてはまた別の機会に説明します。前述の Facebook の GraphAPI は Web-API レベルで実装されています。オープン グラフ プロトコルがそれを形作っています。繰り返しになりますが、Drupal のようなものはフロントエンド レベルで実装されています (ただし、バックエンドはノード パターンを下位レベルで実装していますが、
最後に、ノードベースのアーキテクチャは、従来のドキュメント/ページ ベースの CMS アーキテクチャよりもはるかに柔軟ですが、開発者側で行うプログラミングと構成がより多くなることも意味します。ノードベースのシステムは、最終的に相互接続がはるかに強くなり、そのコンポーネントはより深いレベルで相互に統合されますが、この深いレベルの接続のために、より壊れやすくなる可能性があります - それは分離よりも少ないです個々のモジュールに。個人的には、人々が 90 年代のように電子雑誌としてではなく、アプリケーションのように Web サイトと対話し始めるにつれて、人々がより「ノードベース」になり、「コンテンツベース」ではなくなるという大きな傾向が見られます。プラス、ユーザーとそのアカウント/プロファイルを Web サイトに追加すると、複雑さが劇的に増加します。
「アセット」と言ったのは知っているので、アセットはノード パターンのデータ側をより強調するのに対し、「ノード」はデータ間の接続をより強調すると言います。
しかし、さらに読むために、私が言及したソフトウェアのアーキテクチャを読むことをお勧めします。node.js、JSON、ドキュメント ベースのデータベース、および GraphAPI もチェックしてみてください。これらは、このアセット/ノード ベースのアーキテクチャの考え方にうまく適合しているようです。ウィキペディアにも、これらのパターンに関する優れた情報がいくつかあると確信しています。