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