防止代码重复
在处理多个项目时，请务必确保代码不重复。 代码复制会增加出现缺陷的可能性、更改系统的成本以及代码库中的整体刚度。 要防止重复，请将公共逻辑重构为可跨多个项目使用的可重用库。
为了满足此需求，我们建议开发和维护所有团队都可以依赖并参与的核心项目。 在执行此操作时，请务必确保此核心项目反过来不依赖于任何单个团队的项目；这样可以在促进代码重用的同时实现独立部署。
核心模块中常见的一些代码示例包括：
-
系统范围的配置，例如：
- OSGi配置
- Servlet过滤器
- ResourceResolver映射
- Sling转换器管道
- 错误处理程序(或使用ACS AEM Commons错误页处理程序1)
- 用于权限敏感型缓存的授权servlet
-
实用程序类
-
核心业务逻辑
-
第三方集成逻辑
-
创作UI叠加图
-
创作所需的其他自定义项，如自定义构件
-
工作流启动器
-
跨站点使用的常见设计元素
模块化项目体系结构
这并不能消除多个团队依赖同一组代码并可能需要更新同一组代码的需求。 通过创建核心项目，我们减小了团队之间共享的代码库大小，从而减少了对共享资源的需求，但并未消除对共享资源的需求。
为了确保对此核心包所做的更改不会中断系统的功能，我们建议由高级开发人员或开发人员团队进行监督。 一种选择是让一个团队管理此包的所有更改；另一种选择是让团队提交由这些资源审查和合并的拉取请求。 重要的是，治理模型要由团队设计和同意，并且开发人员应遵循该模型。
管理部署范围
由于不同的团队将其代码部署到同一存储库，因此它们不会覆盖彼此的更改非常重要。 AEM提供了一种在部署内容包（即过滤器）时控制此操作的机制。 xml文件。 过滤器之间不应重叠，这一点很重要。 xml文件，否则，一个团队的部署可能会擦除另一个团队以前的部署。 要说明这一点，请参阅以下精心编制的过滤器文件与有问题的过滤器文件的示例：
/apps/my-company与/apps/my-company/my-site
/etc/clientlibs/my-company与/etc/clientlibs/my-company/my-site
/etc/designs/my-company与/etc/designs/my-company/my-site
如果每个团队明确将其过滤器文件向下配置到他们正在处理的站点，则每个团队可以独立部署其组件、客户端库和站点设计，而无需擦除彼此的更改。
由于这是全局系统路径而不是特定于某个站点，因此应将以下servlet包含在核心项目中，因为此处所做的更改可能会影响任何团队：
/apps/sling/servlet/errorhandler
叠加
叠加经常用于扩展或替换现成的AEM功能，但使用叠加会影响整个AEM应用程序（即，任何叠加的功能更改均可用于所有租户）。 如果租户对覆盖层的要求不同，情况会更加复杂。 理想情况下，业务组应该一起工作以就AEM管理控制台的功能和外观达成一致。
如果不同业务部门之间无法达成共识，可能的解决方案是根本不使用叠加。 相反，请创建功能的自定义副本，并通过每个租户的不同路径公开该副本。 这允许每个租户具有完全不同的用户体验，但这种方法也会增加实施和后续升级工作的成本。
工作流启动器
在存储库中进行指定的更改时，AEM会使用工作流启动器自动触发工作流执行。 AEM提供了多个现成的启动器，例如，用于针对新的和更新的资源执行演绎版生成和元数据提取过程。 虽然这些启动器可以保持原样，但在多租户环境中，如果租户具有不同的启动器和/或工作流模型要求，则可能需要为每个租户创建和维护单个启动器。 这些启动器需要配置为在其租户的更新上执行，同时保持其他租户的内容不变。 通过将启动器应用到特定于租户的指定存储库路径，可轻松实现此目标。
虚 URL
AEM提供了虚名URL功能，可以根据每个页面进行设置。 在多租户场景中，此方法关心的是，AEM无法确保以这种方式配置的虚名URL之间的唯一性。 如果两个不同的用户为不同的页面配置相同的虚路径，则可能会遇到意外行为。 因此，我们建议在Apache Dispatcher实例中使用mod_rewrite规则，这些规则允许将配置中心点与仅出站资源解析程序规则结合使用。
组件组
在为多个创作组开发组件和模板时，请务必有效使用componentGroup和allowedPaths属性。 通过将这些组件有效地与站点设计结合使用，我们可以确保品牌A的作者只能看到为其站点创建的组件和模板，而品牌B的作者只能看到其组件和模板。
测试
虽然良好的架构和开放的通信渠道有助于防止将缺陷引入站点的意外区域，但这些方法并非万无一失。 因此，在将任何内容发布到生产环境之前，必须完全测试平台上正在部署的内容。 这要求各团队在其发布周期中进行协调，并强化了使用尽可能多功能的一套自动化测试的需求。 此外，由于一个系统由多个团队共享，因此性能、安全性和负载测试比以往任何时候都更加重要。
操作注意事项
共享资源
AEM在单个JVM中运行；任何部署的AEM应用程序除了在AEM的正常运行中已占用的资源之外，还会彼此固有地共享资源。 在JVM空间本身内，线程没有逻辑分离，并且AEM可用的有限资源（如内存、CPU和磁盘I/O）也共享。 任何占用资源的租户都不可避免的会影响到其他系统租户。
性能
如果不遵循AEM最佳实践，则可以开发一些使用超出正常范围的资源的应用程序。 例如，触发许多繁重的工作流操作（如DAM更新资产）、对许多节点使用MSM推送修改操作或使用昂贵的JCR查询实时呈现内容。 这些不可避免地会对其他租户应用程序的性能产生影响。
日志记录
AEM为强大的记录器配置提供了现成的界面，利用这些界面可在共享开发环境中发挥我们的优势。 通过为每个品牌指定单独的记录器，根据包名称，我们可以实现一定程度的日志分离。 虽然系统范围内的操作（如复制和身份验证）仍会记录到中央位置，但非共享自定义代码可以单独记录，从而简化每个品牌技术团队的监控和调试工作。
备份和恢复
由于JCR存储库的性质，传统备份在整个存储库中工作，而不是在单个内容路径中工作。 因此，不可能根据租户轻松分离备份。 相反，从备份中恢复将回滚系统中所有租户的内容和存储库节点。 虽然可以使用VLT等工具执行目标内容备份，或者通过在单独的环境中构建包来挑选要恢复的内容，但是
方法不容易包含配置设置或应用程序逻辑，并且管理起来可能比较麻烦。