前端领域模型答案

【问题标题】：Domain models in front end前端领域模型
【发布时间】：2016-10-06 00:32:09
【问题描述】：

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

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

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

报价

可以投赞成票/反对票。
可以加星标。
可由用户创建（进入审核队列）。
用户可以通过（Twitter、Facebook 等）分享。

给定一个用户

未登录时：

可以看到随机报价。
可以对报价投赞成票/反对票。
可以按标题或作者搜索引文。

登录时：

可以创建报价。
可以为报价加注星标。

我对如何在保持 UI 和业务逻辑干净和分离方面实现上述要求感兴趣。

我不是专家，但目前我可以提出这些要求，这些要求将来很可能会改变。

【问题讨论】：

React with Redux（和 Elm 本身）实现了事件溯源的范式，明确分离了表示和“逻辑”，并为其提供了不可变的存储端“左折叠”样式状态更新。
对于业务线应用程序，我倾向于在服务器和非常笨拙的客户端上拥有所有逻辑。我在客户端上有业务逻辑的唯一原因是为了提高性能和用户体验，但最后你不能相信 UI 的状态，所以无论如何都必须在服务器上复制所有这些逻辑。我在客户端中拥有的最复杂的逻辑是视图逻辑。如果我发现业务逻辑正在蔓延到客户端，我会确保这些数据可从服务器返回的有效负载中获得。你在客户端有什么样的业务逻辑？
顺便说一下，对于单页应用程序中的数据同步，我只是监听来自服务器的事件流并重新发出受影响的查询。因此，保持状态最新的逻辑最少。如果您能承受性能损失，那么这是一个好方法。
@plalx 我依赖服务器，因为我可能会使用一些第三方 API 来获取报价，所以我希望我的服务器只向我发送愚蠢的 JSON 数据并让我的客户端处理它。
@CodeYogi 好吧，通过对客户端进行聚合和报价分析，您将失去更多了解您的域的机会。例如，如果在服务器上完成报价收集和分析，您可以跟踪通常提供最佳报价的人以及是否存在趋势等。无论如何，无论您决定什么，我觉得在客户端拥有一个贫血模型通常会更好.业务逻辑封装在服务对象中。然后，控制器将使用这些服务来收集信息、构建视图模型并传达更改。

标签： javascript web architecture domain-driven-design

【解决方案1】：

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

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

【讨论】：

我同意并补充说会有领域知识重复（例如，在前端和后端验证业务规则）但这有点正常，领域知识重复肯定比耦合更好。要说这很正常，当您阅读“错误客户端”时，通常是关于在调用后端函数之前未对其端进行验证的客户端。而且您已经这样做了：当您集成支付网关时，您会阅读文档并在发布之前强制执行必填字段。这就是领域知识的复制。