Javascript 前端的域模型

我最近一直在阅读有关领域驱动设计的文章，但我很少在web应用程序中看到它（或者我可能没有用谷歌搜索它），我认为我们现在也有足够的复杂性来处理web应用程序

我需要一种方法来保持我的模型和业务逻辑干净、耦合最少，并且与框架/库无关。例如，今天我使用AngularJS，明天我可能会将UI切换到ReactJS

话虽如此，我还是试着用一个简单的例子来学习这一点。假设我正在尝试创建具有以下功能的Quote应用程序：

给出一个报价

可以向上/向下投票

可以主演

可以由用户创建（进入审查队列）

用户可以通过（Twitter、Facebook等）共享

给定用户

未记录时：

可以看到随机报价

可以向上/向下投票报价

可以按标题或作者搜索引用

登录时：

可以创建报价

我可以用星号报价

我感兴趣的是如何在保持UI和业务逻辑干净和独立的情况下实现上述要求

---

我不是专家，但目前我可以满足这些需求，这些需求将来可能会发生变化。

您应该在前端和后端（服务器端）实现MVC模式。为了明确划分责任和团队资源/专业知识（api开发人员、UI开发人员），您可以通过REST api和使用各种客户端技术（例如angular、cordova、react等）的UI开发来公开业务逻辑

---

UI开发人员应该能够在没有API的情况下独立开发。他们必须创建自己的模型、视图和控制器（MVC）。类似地，API开发人员应该能够开发业务领域并公开业务或通用语言所需的必要操作（例如CRUD）。API层将有自己的模型、视图和控制器

React with Redux（以及Elm本身）实现了事件源的范例，将表示和“逻辑”明确分离，并为其提供了不可变的存储端“左折”样式的状态更新。对于业务线应用程序，我倾向于将所有逻辑都放在服务器和非常愚蠢的客户端上。在客户机上使用业务逻辑的唯一原因是为了提高性能和用户体验，但最终您无法信任UI的状态，因此所有这些逻辑都必须在服务器上复制。客户机中最复杂的逻辑是视图逻辑。如果我发现业务逻辑正在潜入客户机，我会确保这些数据可以从服务器返回的负载中获得。客户端中有什么样的业务逻辑？顺便说一句，对于单页应用程序中的数据同步，我只需侦听来自服务器的事件流，然后重新发出受影响的查询。因此，最基本的逻辑是保持状态最新。如果您能承受性能损失，那么这是一个很好的方法。@plalx我依赖服务器，因为我可能会使用一些第三方API来获取报价，我希望我的服务器只向我发送愚蠢的JSON数据，让我的客户机处理。@CodeYogi如果在客户机上进行聚合和报价分析，您将失去进一步了解您的域的机会。例如，如果报价收集和分析是在服务器上完成的，那么你可以跟踪谁通常提供最好的报价，以及是否有趋势，等等。不管你怎么决定，我觉得在客户端使用贫血模型通常更好。业务逻辑封装在服务对象中。然后，控制器将使用这些服务收集信息、构建视图模型和传达更改。我同意并补充说，将存在领域知识重复（例如，在前端和后端验证业务规则），但这是一种正常现象，领域知识重复肯定比耦合好。要说这是正常的，当您阅读“Fally client”时，通常是关于在调用后端函数之前未在其端执行验证的客户端。你已经做到了：当你集成一个支付网关时，你在发布之前阅读文档并在你的终端强制执行必填字段。这就是领域知识的复制。