我目前正在设计一个多渠道商业系统的架构，该系统将具有多个不同的前端演示，这些演示针对设备和渠道（用户类型和位置）进行定制。我面临的挑战是如何最好地确保我们正在以减少前端演示层重复的方式开发核心商务平台。
以下是我们需要支持的不同前端演示层的示例：
- 面向消费者的传统桌面网站
- 面向消费者的移动优化网站
- 面向消费者的本地移动应用程序（iOS/Android）
- 面向客户支持代表的客户支持中心网站
- 基于Instore售货亭的网站，供消费者在实体店购物
- 其他（微型网站和其他利用各种技术的网站，如Angular、PHP、.NET等）
现在，我知道了围绕分层架构（表示层、业务层、数据层）和通用设计模式的最佳实践，以解决单个应用程序中的前端挑战（如MVC、验证器、拦截器）。然而，这些原则都没有解释如何和在哪里在支持多个前端时最好地封装您的演示文稿特定的业务逻辑。
因此，我的问题是在开发这样一个系统以确保每个前端应用程序不会复制前端业务逻辑时，应该遵循哪些良好的实践和原则
在过去，我使用不同的方法开发了许多具有类似需求的应用程序。。。其中有些效果不错，有些效果不太好。但每次我都觉得自己在为一个常见问题发明一个解决方案，而且必须有一些最佳实践和原则可以利用。
我询问的具体挑战的快速示例
我们所有的前端应用程序都必须支持注册新客户帐户的功能。登记表将包含电子邮件、密码和客户地址信息（街道、城市、邮政编码等）等信息。提交表单时，在系统中创建帐户并向用户发送验证电子邮件之前，需要进行某些琐碎和非琐碎的验证。例如：
- 电子邮件地址模式验证规则
- 确保系统中不存在电子邮件地址
- 密码复杂性规则
- 地址验证（通过第三方地址验证/标准化系统）
在大多数情况下，这些验证规则需要在所有前端系统中强制执行，尽管每个前端的注册流可能略有不同，并且可能只包含字段的一个子集。那么，为前端提供API以使每个前端不会重复正确验证和处理注册所需的各种步骤，有哪些好的做法？例如，如果我们决定更改密码复杂性规则或地址验证规则等，我们可以如何最好地设计系统，使我们不必使用这种新的验证逻辑来更改所有各种前端应用程序。
需要明确的是，我并不关心将所有前端共享的核心业务逻辑（即帐户创建服务、地址验证服务、帐户查找服务等）放在哪里。这些模式通常在博客、书籍和论坛中讨论。我的问题特别涉及业务逻辑，它通常与表示层紧密耦合。一些问题总是浮现在我的脑海中。
- 我们是否应该提供演示服务层，支持所有前端操作，包括表单验证和通过web服务进行处理？还是每个前端都应该拥有它的表示逻辑，因为"没有两个前端是相似的"
- 如果我们确实创建了表示服务层，我们如何提供服务来解决每个前端的细微差异？我们是为每个前端提供不同的服务/端点，还是提供每个前端在调用我们的服务时通过的不同"上下文"
- 这个表示服务层是否控制错误消息并向每个前端返回适当的上下文感知消息，或者我们应该只传递错误代码并让前端拥有它
- 等等
没有什么神奇的方法可以在您的所有前端中拥有一致的验证规则，尤其是当您混合了不同的技术和环境（PHP、JS、原生应用程序）时。如果验证规则很复杂，那么实现它的代码总是很复杂的。
您可以做的是将验证作为核心功能。您可以去掉表示层中的所有验证，并将其转移到所有前端使用的公共应用程序层。通过这种方式，您的演示文稿将有一个表单，并将其发送到服务器，以在用户填写表单时获得验证错误。这可以使用web中的AJAX或本地应用程序中的REST API调用来完成。如果做对了，用户体验不会受到损害。
在这种情况下，总是有一个折衷方案：您将花费更少的时间来维护验证代码，而代价是稍差的响应和/或用户体验。
如果我能正确理解你的问题，我会这样做：
使用策略模式根据抽象实现每个演示。使用工厂来实例化您的具体策略。使用MVC来分离层，并使用Observer来更新视图层中的策略。
希望能有所帮助。