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

Question

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

• 调用6种不同的服务(Soap、Rest (XML/JSON))来收回客户数据，并将其作为servlet公开给我的单个页面应用程序(JS自主应用程序)，该应用程序托管在我的一个客户端库上。

知道这个处理不需要任何AEM功能(不需要内容，也不需要AEM云集成，也不需要个性化)。

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

你认为如何？

Answer 1

我可以想到将代码放置在AEM中可能引起的4个问题：

• 因为你需要一个付费的实例，所以调用更昂贵。
• 引入新版本的AEM时的额外费用
• 如果停止使用AEM或您需要切换平台，则需要额外费用。
• 开发人员可用性/成本与Java开发人员的比较