前端的领域模型

Question

最近我一直在研究领域驱动设计，但是很少看到它被应用在Web应用程序中（或者说我没能够找到），我认为我们现在在Web应用程序中已经有足够复杂的问题需要解决。

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

话虽如此，我正在尝试通过一个简单的示例来学习它。假设我要创建以下功能的报价应用程序：

给定一条报价

1. 可以投票 / 反对。
2. 可以加星标记。
3. 可以由用户创建（进入审核队列）。
4. 用户可以通过（Twitter、Facebook等）分享它。

给定一个用户

未登录时：

5. 可以查看随机报价。
6. 可以投票 / 反对一条报价。
7. 可以通过标题或作者搜索报价。

登录后：

1. 可以创建报价。
2. 可以加星标记。

我感兴趣的是如何在保持UI和业务逻辑清晰分离的同时实现上述要求。

我不是专家，但目前我可以提出这些要求，而这些要求可能会在未来发生变化。

- CodeYogi

---

React与Redux（以及Elm本身）实现了事件源范式，具有清晰的演示和“逻辑”分离，使用不可变存储和“左折叠”样式状态更新。 - Alexey Zimarev

对于业务应用程序，我倾向于在服务器上拥有所有逻辑和非常简单的客户端。我将业务逻辑放在客户端的唯一原因是为了提高性能和用户体验，但最终您无法信任UI的状态，因此所有逻辑都必须在服务器上复制。我在客户端中拥有的最复杂的逻辑是视图逻辑。如果我发现业务逻辑正在渗入客户端，我会确保从服务器返回有效负载中获取这些数据。你在客户端中有什么样的业务逻辑？ - plalx

顺便说一下，对于单页应用程序中的数据同步，我只需监听来自服务器的事件流并重新发出受影响的查询即可。因此，保持状态最新的逻辑非常少。如果您可以承受性能损失，那么这是一个不错的方法。 - plalx

@plalx，我依赖服务器，因为我可能使用一些第三方API来获取报价，所以我希望我的服务器只是发送愚蠢的JSON数据，让客户端处理它。 - CodeYogi

@CodeYogi 如果在客户端进行聚合和报价分析，您将失去了更多了解您领域的机会。例如，如果报价收集和分析在服务器上完成，您可以跟踪通常提供最佳报价的人以及是否存在趋势等。无论如何，无论您决定什么，我认为在客户端拥有贫血模型通常更好。业务逻辑封装在服务对象中。然后，控制器将使用这些服务来收集信息、构建视图模型和传达更改。 - plalx

我从未真正遇到过富领域模型在客户端上有益的情况，但这可能是我正在构建的系统的品种所致。例如，如果我设计一个浏览器内 IDE，那么情况可能会非常不同，因为我可能希望将文档建模在客户端。尽管如此，您仍然可以从客户端服务返回丰富的模型。 - plalx

Answer 1

您应该在前端和后端（服务器端）都实现MVC模式。为了清晰地分离职责，以及利用团队资源/专业知识（API开发人员、UI开发人员），您可以通过REST API公开业务逻辑，并使用各种客户端技术进行UI开发（例如angular、cordova、react等）。

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

- alltej

---

我同意并且补充说，领域知识重复是不可避免的（例如在前端和后端都验证业务规则），但这是正常的，领域知识重复绝对比耦合更好。当你了解“故障客户端”时，通常是指在调用后端功能之前，客户端未在其端执行验证。而你已经这样做了：当你集成支付网关时，你会阅读文档并在提交之前在你的端口强制执行必填字段。这就是领域知识重复的体现。 - Phillippe Santana