我目前正在为多渠道商务系统设计架构，该系统将有多个不同的前端演示，这些演示针对设备和渠道（用户类型和位置）量身定制。我面临的挑战是如何最好地确保我们以减少前端表示层重复的方式开发核心商务平台。
以下是我们需要支持的不同前端演示层的示例：
- 面向消费者的传统桌面网站
- 面向消费者的移动优化网站
- 面向消费者的原生移动应用程序 (iOS/Android)
- 客户支持代表的客户支持中心网站
- 基于店内信息亭的网站，供消费者在实体店购物
- 其他（微型网站和其他利用各种技术，如 Angular、PHP、.NET 等）
现在，我了解了围绕分层架构（表示层、业务层、数据层）和常见设计模式的最佳实践，以解决单个应用程序中的前端挑战（例如 MVC、验证器、拦截器）。但是，这些原则都没有解释在面对支持多个前端时如何以及在何处最好地封装特定于演示文稿的业务逻辑。
那么，我的问题是，在开发这样的系统以确保每个前端应用程序不会重复前端业务逻辑时，应该遵循哪些好的实践和原则？
过去，我使用不同的方法开发了许多具有此类要求的应用程序……其中一些工作得很好，一些工作得不太好。但每次我都觉得自己正在为一个常见问题发明一个解决方案，并且必须有一些最佳实践和原则可以利用。
我正在询问的具体挑战的快速示例
我们所有的前端应用程序都必须支持注册新客户帐户的能力。注册表将包含电子邮件、密码和客户地址信息（街道、城市、邮编等）等信息。提交表单后，在系统中创建帐户并将验证电子邮件发送给用户之前，需要进行某些琐碎和非琐碎的验证。例如：
- 电子邮件地址模式验证规则
- 确保系统中不存在电子邮件地址
- 密码复杂性规则
- 地址验证（通过第三方地址验证/标准化系统）
在大多数情况下，这些验证规则需要在所有前端系统中强制执行，尽管每个前端的注册流程可能略有不同，并且可能只包含字段的一个子集。那么，为前端提供 API 以使每个前端不会重复正确验证和处理注册所需的各种步骤，有哪些好的做法呢？例如，如果我们决定更改密码复杂性规则或地址验证规则等 - 我们如何最好地设计系统，这样我们就不必使用这种新的验证逻辑更改所有各种前端应用程序。
为了清楚起见，我不关心将所有前端共享的核心业务逻辑放在哪里（即帐户创建服务、地址验证服务、帐户查找服务等）。这些模式通常在博客、书籍和论坛中讨论。我的问题与通常与表示层紧密耦合的业务逻辑特别相关。有些问题总是浮现在我的脑海中。
- 我们是否应该提供一个表示服务层来支持所有前端操作，包括表单验证和通过 Web 服务进行处理？还是每个前端都应该拥有它的表示逻辑，因为“没有两个前端是一样的”？
- 如果我们确实创建了一个表示服务层，我们如何提供解决每个前端细微差异的服务？我们是否为这些前端中的每一个提供不同的服务/端点，或者只是提供每个前端在调用我们的服务时传递的不同“上下文”？
- 这个表示服务层是否控制错误消息并将适当的上下文感知消息返回给每个前端，还是我们应该只传回错误代码并让前端拥有它？
- ETC