Architecture 在AEM层上托管复杂的编排/转换/业务逻辑是一个好主意吗

从设计角度来看，您认为在AEM层上开发复杂的业务规则和流程编排是一个好主意吗，例如：

• 调用6个不同的服务（Soap、Rest（XML/JSON））来检索客户数据，并将其作为servlet公开，以将其提供给托管在我的ClientLib上的单页应用程序（JS自治应用程序）

知道此处理不需要任何AEM功能（不需要内容、AEM云集成或个性化等）

我的猜测是否定的，将这段代码转移到更便宜的服务器会更明智。 即使从组织的角度来看，将所有这些连贯的功能放在同一个包上，由同一个团队维护也是有意义的

---

您认为如何？

我可以想到将代码放在AEM中会导致4个潜在问题：

• 缩放成本更高，因为您需要付费实例
• 引入新版本AEM时的额外成本
• 如果AEM中断或您需要切换平台，则会产生额外费用
• 与Java开发人员相比，开发人员可用性/成本

---

我认为这是基于观点的。AEM毕竟使用了一个Servlet引擎，就像Tomcat和Glassfish一样，没有什么可以阻止您在OSGi捆绑包中使用业务逻辑。只要您还使用AEM的CMS功能，因此已经有一个付费实例，我个人喜欢在AEM中使用它，因此只有一个代码库和一个部署机制。如果它是一个独立的单页应用程序，我会选择Tomcat或类似的应用服务器。我不认为实例是付费的这一事实是做出这种架构选择的一个因素。因为你会在一台服务器上增加很多负载，你需要支付新的实例来承载一个不使用任何AEM的代码。我的意思是，我不会为AEM购买一个许可证，让它仅仅作为一个定价过高的应用服务器使用，但如果你已经有了一个，那么在它上运行额外的逻辑并没有什么坏处。我在问自己（通过堆垛机）这个问题是因为我认为它很伤人。至少出于Shiraz下面列出的原因，在aem上什么是正确的最低要求，至少我们必须使用构建视图所需的逻辑，或者检索客户数据，……这些都是有效的观点，但使用Apache Sling作为后备方案可能很容易缓解这些问题。如果您不使用“AEM能力”则AEM和吊索是等效的。