在伦敦 DevCon 上与一些人交谈并查看记录管理源代码后，我注意到实际上没有关于如何实现自定义文档生命周期的好例子。我知道有规则和内容建模甚至工作流的示例，但这些解决方案不能真正用于实现像记录管理这样更严肃的东西。
我想知道的是如何有效地将 Java 解决方案（我在 OO 和 Java 方面的经验比 Alfresco 更多）映射到 Alfresco。什么应该定义为 Java 类，什么应该是内容模型中的类型/方面。何时更倾向于行为而不是规则以及何时实际使用工作流。在我最初的几个项目中，我使用工作流来实现文档生命周期，我在工作流节点中编写了很多业务/领域逻辑 - 作为操作 (JS)。我后来发现这很难维护，因为您在工作流中有一些代码，一些在存储库中作为脚本（数据字典/脚本），一些 Java，......
记录管理是开始学习并了解实施完整文档生命周期的一些最佳实践的好例子吗？还有其他资源吗？
我最苦恼的是如何在 java 中实现完整的生命周期以及如何“集中”业务/域逻辑。
ECM 的范围很大，因此很难提出完全通用的指导方针：您确实需要坚持您必须解决的用例并找到最佳解决方案。RM是如何在 Alfresco 之上实施记录管理解决方案的一个很好的示例，但在实施 Web 发布流程时它绝对没用，而WCM QS是您想要查看的起点。
就 Alfresco 为开发人员提供的所有 API 而言，它们的内在特征最终是了解何时使用它们的最佳资源。让我们看看我是否能理解（至少是其中最重要的）它们。
内容类型
这是您始终需要开始实施 Alfresco 项目的地方。您需要与对您需要实施的文档处理具有深厚领域知识的人密切合作，并为不同的文档生命周期定义根元素。在 Alfresco 中，您必须为给定节点分配一种且只有一种内容类型。这是在内容创建时完成的，并且在内容生命周期中并不经常更改。因此，内容类型通常用于标识具有完全不同生命周期的内容项（例如cm:document和ws:article），并且定义内容类型意味着提取将在整个文档生命周期中使用或有用的基本元数据属性。
方面
虽然内容类型基本上是文档的静态垂直分类和丰富，但方面是它们的动态表亲。与内容类型相反，您可以动态地应用或删除方面，而对内容节点的破坏性后果几乎没有。它们可以或不使用更多元数据来丰富文档，并且可以应用于项目而不管其内容类型如何。这些特性使方面可能成为 Alfresco 内容模型最灵活的特性：您可以使用它们来标记内容或启用/禁用在不同内容生命周期之间共享的操作（例如cm:versionable，rma:filePlanComponent）。从本质上讲，方面旨在处理在几个不同的生命周期或生命周期步骤中出现的横切概念。
行为
在这里，我们开始概述如何在您的 Alfresco 解决方案中添加逻辑。行为是由特定触发器触发的自动计算，其中触发器被定义为 [type/aspect, policy] 对（例如 [ cm:versionable, onCreateNode]）。它们通常在触发触发器的事件的同一事务中执行，无法保证执行顺序，也没有协调或编排。这使得它们非常适合自动内容生成或处理（例如创建缩略图或更新某些元数据），这需要成为内容生命周期的组成部分，但严格来说不是正式流程的一部分。
它们是正常操作或工作流程的辅助或补充操作。它们需要 Java 编码，因此构成了解决方案中相当固定的部分。您通常在完成内容建模阶段之后和开始设计工作流程之前立即识别和设计行为。
规则
与行为类似，规则是根据特定事件触发的，但它们比它们更通用和动态。您可以在运行时仅在文件夹上配置规则，并将它们绑定到文件夹内发生的事件。这使得它们非常适合在您的内容存储库中创建特殊存储桶（例如，每当将内容添加到特定文件夹时发送电子邮件），当您处理其中的内容时会发生副作用。它们被实现为文件夹中的隐藏节点，因此是导出的组成部分：理论上，您可以在不同的 Alfresco 实现中借用它们，前提是所需的部分可用。
它们通常在一段逻辑适用于几种不同类型的内容时使用，但可能不是受影响类型的所有项目，并且仅当您可以将所有受影响的内容节点存储在存储库的子分支中时。即使这样的约束听起来很繁重，但规则被证明是一个非常方便的工具（例如，为所有image/png在 /images 中具有 mime 类型的 png 文档生成一个缩略图）。
行动
Actions are bundled pieces of logic that can be invoked against a node on demand. They're the building blocks for rules, and often used within workflows (e.g. send an email). They are also handy to be directly bound to UI components/buttons, in order to allow the user to be directly exposed to available features of your application. You normally end up developing an action when you need (of want to enable) reusing the same piece of logic in different contextes, such as a workflow, a rule and/or direct user interaction.
Workflows
This is probably the core business of document management: workflows allow you to build a coordinated process that guides users through a defined sequence of steps, basically implementing a human algorithm. Workflows allow you to write custom code, but for the sake of maintainability you probably want to limit such code to the bare minimum of what the workflow itself needs in order to execute, and externalize more complex operations to actions or scripts.
If you're doing document management, the design and implementation of a workflow can start right after content modeling, possibly spawning several other development activities such as accessory actions and scripts, and they're likely to last until you call your code feature complete, and you start fiddling with all the infinite change requests or leftovers on the UI :-)