ECMの範囲は非常に広いため、完全に一般的なガイドラインを作成することは非常に困難です。実際には、対処しなければならないユースケースに固執し、それに最適なソリューションを見つける必要があります。RMは、Alfresco上にレコード管理ソリューションを実装する方法の優れた例ですが、 WCM QSが出発点として見たいWeb公開プロセスの実装に関しては、まったく役に立ちません。
Alfrescoが開発者に提供するAPI全体では、APIの内部特性は、最終的にはいつ使用するかを理解するための最良のリソースです。それらの中で（少なくとも最も重要な）意味を理解できるかどうか見てみましょう。
コンテンツタイプ
これは、常にAlfrescoプロジェクトの実装を開始する必要がある場所です。実装する必要のあるドキュメント処理について深いドメイン知識を持つ人と緊密に連携し、さまざまなドキュメントライフサイクルのルート要素を定義する必要があります。Alfrescoでは、特定のノードに1つだけのコンテンツタイプを割り当てる必要があります。これはコンテンツの作成時に行われ、コンテンツのライフサイクルに沿って変更されることはあまりありません。したがって、コンテンツタイプは通常、ライフサイクルが根本的に異なるコンテンツアイテム（cm:documentおよびなどws:article）を識別するために使用されます。コンテンツタイプを定義することは、ドキュメントのライフサイクル全体で使用または役立つ基本的なメタデータプロパティを抽出することを意味します。
側面
コンテンツタイプは基本的に静的な垂直分類とドキュメントの強化ですが、アスペクトは動的ないとこです。コンテンツタイプとは対照的に、コンテンツノードに破壊的な結果を与えることなく、アスペクトを動的に適用または削除できます。ドキュメントをより多くのメタデータで強化できる場合とできない場合があり、コンテンツタイプに関係なくアイテムに適用できます。これらの特性により、Alfrescoコンテンツモデルの最も柔軟な機能となる可能性があります。これらの特性を使用して、コンテンツにマークを付けたり、さまざまなコンテンツライフサイクル間で共有される操作を有効/無効にしたりできます（例cm:versionable）rma:filePlanComponent。本質的に、アスペクトは、いくつかの異なるライフサイクルまたはライフサイクルステップで発生する横断的な概念を処理することを目的としています。
行動
ここから、Alfrescoソリューションにロジックを追加する方法の概要を説明します。ビヘイビアーは、特定のトリガーによって起動される自動計算であり、トリガーは[タイプ/アスペクト、ポリシー]のペア（[ cm:versionable、onCreateNode]など）として定義されます。これらは通常、トリガーを起動するイベントの同じトランザクション内で実行され、実行の順序は保証されず、調整やオーケストレーションもありません。これにより、コンテンツのライフサイクルの不可欠な部分である必要があるが、厳密には形式化されたプロセスの一部ではない自動コンテンツ生成または処理（サムネイルの作成やメタデータの更新など）に最適です。
これらは、通常の操作またはワークフローのアクセサリまたは補足操作です。これらはJavaコーディングを必要とするため、ソリューションのかなり固定された部分を形成します。通常、コンテンツモデリングフェーズを終了した直後、ワークフローの設計を開始する前に、動作を識別して設計します。
ルール
動作と同様に、ルールは特定のイベントでトリガーされますが、ルールはそれらよりもはるかに一般的で動的です。実行時にフォルダーにのみルールを構成し、フォルダー内で発生するイベントにルールをバインドできます。これにより、コンテンツリポジトリ内に特別なバケットを作成するのに理想的です（たとえば、コンテンツが特定のフォルダに追加されるたびに電子メールを送信します）。この場合、コンテンツリポジトリ内のコンテンツを処理すると副作用が発生します。これらはフォルダ内の非表示ノードとして実装されているため、エクスポートの不可欠な部分です。理論的には、必要な部分が利用可能であれば、さまざまなAlfresco実装でそれらを借りることができます。
これらは通常、ロジックの一部がいくつかの異なるタイプのコンテンツに適用される場合に使用されますが、影響を受けるタイプのすべてのアイテムに適用されるわけではなく、影響を受けるすべてのコンテンツノードをリポジトリのサブブランチ内に格納できる場合にのみ使用されます。そのような制約が重く聞こえるかもしれませんが、ルールは非常に便利なツールであることがわかります（たとえばimage/png、/ imagesにmimeタイプを持つすべてのpngドキュメントのサムネイルを生成します）。
行動
アクションは、オンデマンドでノードに対して呼び出すことができるバンドルされたロジックです。これらはルールの構成要素であり、ワークフロー内でよく使用されます（メールの送信など）。また、ユーザーがアプリケーションの利用可能な機能に直接触れることができるように、UIコンポーネント/ボタンに直接バインドするのにも便利です。通常、ワークフロー、ルール、直接のユーザーインタラクションなど、異なるコンテキストで同じロジックを再利用する必要がある場合（有効にしたい場合）にアクションを開発することになります。
ワークフロー
これはおそらくドキュメント管理のコアビジネスです。ワークフローを使用すると、基本的に人間のアルゴリズムを実装して、定義された一連の手順を通じてユーザーをガイドする調整されたプロセスを構築できます。ワークフローを使用するとカスタムコードを記述できますが、保守性を高めるために、ワークフロー自体が実行するために必要な最小限のコードに制限し、より複雑な操作をアクションまたはスクリプトに外部化することをお勧めします。
ドキュメント管理を行っている場合、ワークフローの設計と実装はコンテンツモデリングの直後に開始でき、アクセサリアクションやスクリプトなどの他のいくつかの開発アクティビティが発生する可能性があり、コード機能が完了したと呼ぶまで続く可能性があります。そして、UIのすべての無限の変更要求または残り物をいじり始めます:-)