Moohar 归档

为什么选择 Domino？

2024年1月27日

我是一名 Domino 开发者。 虽然这已经不是我正式的职位名称，但我仍然在使用 Domino 开发 Web 应用程序。 这当然不是一个热门选择，当在谈话中提到它时，人们大多感到困惑。 有些人认为 Domino 是一个已经退役、不再使用的产品，而另一些人甚至从未听说过它。 我觉得我的一些非技术朋友仍然在试图弄清楚披萨和电脑有什么关系。 在 2021 年 5 月，为了配合 HCL Domino 12 版本的发布，我开始为那些从未考虑过将其作为应用程序开发平台的人写一篇 Domino 的介绍。 我本打算解释我是如何使用 Domino 的，我喜欢哪些部分，以及应该避免哪些部分。 但像往常一样，我分心了，没有完成，时机也过去了。 鉴于我计划探索构建一个 Domino 替代方案需要什么，看来一个好的起点是完成那篇解释我喜欢 Domino 什么的帖子，并明确我想要重现什么，以及我想要避免什么。

什么是 Domino？

首先，让我们澄清一下 Domino 是什么。 早在 1989 年，Lotus Development Corporation 发布了 Lotus Notes。 1995 年，IBM 收购了 Lotus，但品牌和名称保持不变。 1996 年，为 Lotus Notes 4 发布了一个名为 Domino 的服务器插件，它允许将 Notes 应用程序呈现为网页。 当 4.5 版本发布时，Web 引擎被集成到服务器中，从那时起，客户端被称为 Lotus Notes，服务器被称为 Lotus Domino。 2012 年，IBM 放弃了 Lotus 品牌，因此它变成了 IBM Notes 和 IBM Domino。 然后在 2019 年，IBM 将该产品出售给 HCL，于是我们得到了现在的名称，HCL Notes 和 HCL Domino。 就我个人而言，我倾向于省略公司名称，主要在谈话中使用“Domino”。 我这样使用是因为它没有那么大的负面含义，而且从技术上讲，对于我使用该产品的方式来说是正确的。 当我使用“Notes”这个术语时，那是因为我正在谈论客户端的某些特定内容。

我的经验

我从 2001 年开始使用 Domino，当时我在 IBM 工作。 我是内部 Domino 环境的支持团队的一员，该环境为所有 IBM 员工托管邮件和应用程序。 这个团队没有参与 Domino 的开发。 我们偶尔会预览新版本，但主要情况下我们被视为内部客户。 我强调这一点是为了明确我没有影响产品的方向。 事实上，自从离开 IBM 并成为付费客户以来，我的声音更大了。 我开辟了一个利基市场，编写工具和自动化程序来协助各种任务和项目。 但是，我想全职进行应用程序开发，因此在 2007 年，我接受了另一家公司的职位，担任 Domino 开发者。 我的新角色是开发、维护和支持在企业日常运营中使用的 Domino 应用程序。 当我开始时，大多数应用程序都使用 Notes 客户端，但是将这些应用程序迁移到基于 Web 的应用程序的工作已经开始，这也是我被招聘的部分原因。 在接下来的六年里，我都在编写 Domino 的 Web 应用程序。 我为我所做的工作和我开发的应用程序感到自豪，这些年来我收到了一些非常赞赏的反馈。 似乎公司也很满意，并且在一个错误的尝试中克隆了我，他们将我提升为团队领导，以便除了应用程序之外，我还可以培养人才。 结果好坏参半，但开发仍在继续，并且仍然在 Domino 中。

Domino 的替代方案

2014 年，我工作的公司被收购并整合到一个更大的组织中。 正如你可以想象的那样，这种整合给 IT 环境带来了许多变化。 不久之后，我们将电子邮件迁移到了 Exchange/Outlook。 简单的文档存储库和 Quickr 站点慢慢地转移到了 SharePoint。 Sametime 坚持了一段时间，但最终被 Skype For Business 取代，Skype For Business 很快又被 Teams 取代。 但是，自定义应用程序是另一回事，没有明显的简易替代方案。 在整合后不久，我的工作是介绍我们如何使用 Domino 以及我们开发了哪些应用程序的概述。 我觉得我的新同事最初认为 Domino 是一个糟糕的电子邮件系统，但随后惊讶地发现它的使用如此广泛，并且对我们的业务至关重要。 毫不夸张地说，Domino 支持着企业的大部分业务。 这是当时我们使用 Domino 的一些方面的删节列表，其中包括：

包括简单的文档存储库和典型的流程/审批应用程序，我们有 100 多个 Domino 应用程序在积极使用中。 然而，仍然有人抵制继续使用 Domino，部分原因是当时 IBM 似乎忽略了该产品，部分原因是它对更广泛的组织的大部分人来说是未知的。 我现在的任务是审查 Domino 的替代方案，并详细说明迁移计划会是什么样子，或者证明为什么我们应该继续在 Domino 中进行应用程序开发。 我们审查了开源选项，我们研究了 Microsoft 的产品，我们研究了 SAP，我们研究了 IBM 的其他产品，我们审查了六个应用程序构建器。 我们断断续续地花了两年时间审查替代方案，但没有一个似乎是合适的替代方案。 老实说，我渴望逃离 Domino 及其所有的怪癖和挫折。 在多年来一直被告知 Domino 有多么糟糕之后，我期望找到各种更优秀的替代方案。 我惊讶地发现 Domino 是无与伦比的，取代它将需要多种产品的组合，并带来全新的一系列挑战和挫折。 事实证明，Domino 是一个很好的应用程序开发平台。 像所有事物一样，它有优点和缺点，但它的优势在于企业关心的领域，而它的缺点是可以管理的。 帮助是 IBM 最终与 HCL 合作，我们得到了一个新版本，但最终我认为我们坚持使用 Domino 的原因有三个：安全性、作为一个完整的软件包和成本。

但是 UI 太糟糕了

一些以前使用过 Notes/Domino 的人现在可能认为我失去了视角，经过 24 年，我已经被洗脑了。 我猜你有一些关于 Notes 有多么糟糕的真实恐怖故事，并且很乐意告诉我我错了。 问题是我同意，Notes 客户端是一团糟。 这是一个用户体验的噩梦，我积极地阻止它的使用。 字段看起来不像字段。 它有三种不同类型的工具栏。 它有三种类型的搜索，但似乎无法正常工作。 有一个很小的属性框，对于某些事情来说至关重要，但在你需要它的时候却被隐藏起来。 键盘快捷键很奇怪。 而且它很慢，并且总是挂起。 暂时做一个辩护者，1.0 版本于 1989 年为 DOS 和 OS/2 发布。 意图是 Notes 在所有平台上保持一致，并且 1989 年 GUI 的标准还很薄弱，因此我认为 Lotus 采用了当时最好的想法并提出了他们自己的标准。 然后，随着后续版本的发布，一个关键目标是保持向后兼容性。 由于 Domino 中的几乎所有内容都是自定义应用程序，因此如果不给所有现有客户带来大量工作、测试并可能重新开发他们的应用程序，就无法使 GUI 组件现代化。 因此，这些组件仍然像 35 年前一样。 按照 1989 年的标准，Notes 客户端可能很棒。 虽然对向后兼容性的优先考虑解释了某些奇怪的视觉效果，但这并不能成为其他领域缺乏进展的理由。 比如为什么属性框仍然如此之小？ 为什么我不能重新排序工作区上的选项卡？ 为什么我不能将键盘快捷键映射为取消选择所有文档？

谁需要客户端

好消息是您不再需要客户端了。 正如我之前提到的，从 1996 年的 4.5 版本开始，服务器现在支持 HTTP 并将应用程序作为网页提供。 真正令人印象深刻的是，这无需任何额外的开发即可工作。 像往常一样在设计器客户端中构建您的应用程序，服务器将自动将所有表单、视图、操作和导航转换为 Web 内容。 1996 年的低代码 Web 开发！ 问题是这些页面看起来，并且仍然看起来像 1996 年的网页，并且任何用户交互都需要完整的页面加载。 使用 JavaScript，但非常谨慎，并且没有 CSS。 该技术在当时令人印象深刻，但今天看起来和功能都很糟糕。 不用担心，Domino 提供了各种方法将您自己的自定义 HTML 注入到页面中，以使它们看起来和工作起来像现代 Web 应用程序一样。 您可以针对页面的小部分执行此操作，并让 Domino 自动生成其余部分，或者您可以完全禁用自动生成，并像使用任何其他技术一样开发 Web 前端。 借助 JavaScript 和 CSS 库支持，您可以完全控制用户界面以及 Domiono 后端的所有优点，我稍后会讲到。 我的公司就是这样开发其 Web 应用程序的。 我们构建了一个库，该库最初模仿了 Notes 客户端的功能，但具有现代外观。 然后，我们使用单页应用程序框架扩展了该库。 IBM 也有类似的想法，因为他们在 8.5 版本中引入了 XPages。 这提供了一种使用 Domino 作为后端构建外观现代的单页 Web 应用程序的方法。 它基于 JavaServer Faces 并使用 Dojo 作为前端。 我相信意图是这将取代传统的 Notes 客户端和“经典”Domino Web 开发，但是这将需要重新开发应用程序，因此采用速度非常缓慢，并且需要维护较旧的技术以实现向后兼容性。 HCL 还引入了各种无需使用 Notes 客户端即可访问 Domino 的方法。 在 10 版本中，他们引入了一种新的 Domino 查询语言 (DQL) 并添加了对 node.js 的支持以查询 Domino 应用程序。 他们还一直在慢慢扩展 REST API。 这意味着您可以使用任何与 HTTP 通信的前端。 关于 Domino 的最大抱怨之一，它的用户界面，可以通过使用 Web 来巧妙地绕过。 问题仍然存在，为什么要使用它的后端。

数据库

Domino 的核心是数据库。 NSF（Notes 存储设施）是一个 NoSQL、面向文档的分布式数据库。 它领先于时代，并提供了我在任何同类竞争对手中都未见过的安全功能。 我发现面向文档的数据库特别擅长支持工作流应用程序、替换基于纸张的表单以及通常建模企业需要存储的那种数据。 在业务需求始终在变化的现实世界中，拥有面向文档的数据库的灵活性非常有用。 因此，我发现对于我需要进行的开发来说，它要快得多。 像 MongoDB 这样的 NoSQL 数据库的日益普及表明我并不孤单。 Domino 数据库的最强大功能是其安全性。 这从访问控制列表或 ACL 开始。 ACL 提供七个广泛的访问级别，并提供细化此级别的选项，以用于诸如创建和删除文档之类的特定操作。 它支持显式名称、分层名称和组。 它可以区分服务器和用户。 您可以为未经身份验证的用户设置的访问级别与经过身份验证但未列出的用户不同。 您可以将名称和组映射到角色。 它可以做很多事情。 经常被忽略的是 ACL 的双重级别，您可以将应用程序中的数据和设计元素分类为公共，然后单独控制对这些元素的访问。 这对于面向公共的应用程序特别有用，在这种应用程序中，您可能希望允许匿名用户访问应用程序的着陆页和一些关键文档，而不是大多数应用程序。 Domino 安全性真正脱颖而出的是读者和作者字段提供的文档级安全性。 将读者字段添加到文档中，只有该字段中列出的那些用户（或组或角色）才能访问该文档。 您可以根据需要添加任意数量的读者字段，它们可以是计算的或用户可编辑的。 借助此系统，可以轻松地为即使是最复杂的场景创建安全模型。 一个实用的例子是年度评估系统。 每次评估都需要由员工、经理、当地人力资源团队和全球人力资源主管看到。 数据库中的任何两个文档都不会具有需要访问它的相同人员列表。 在 Domino 中，这可以通过使员工和经理字段成为读者字段来实现。 然后添加一个计算的读者字段，该字段根据员工的位置计算出当地人力资源团队的组名。 最后添加一个具有人力资源主管角色的静态值的计算的读者字段。 显然，有办法在其他平台上执行此操作。 关系数据库提供行级安全性，但它往往是基于角色的，这在此示例中不起作用。 一种常见的方法是将安全逻辑添加到应用程序中，并生成一个查询以仅返回适当的记录。 这里的问题是，如果有人直接访问数据库，无论是偶然还是恶意，他们都可以看到所有记录。 MongoDB 具有一个编辑聚合功能，可以实现接近我们所需的功能。 但是，据我了解，这类似于关系数据库中的查询，并且没有任何阻止开发人员通过另一种没有该安全逻辑的方法访问文档集合。 我想说的是，在我见过的所有其他平台中，这种类型的安全性是通过在数据库和用户之间添加一个层来实现的。 每一层都可能是一个故障点，并且并非总是只有通过该安全层才能访问数据。 相比之下，Domino 在记录级别内置了这种安全性。 读者字段很容易添加到文档中，并且一旦添加，始终会受到尊重。 这使得开发人员很难犯错误并留下通往这些文档的开放路径。 它不是万无一失的，我们仍然需要审核我们的工作。 但是，与其他解决方案相比，一旦经过审核，您可以对数据的安全性具有更高的信心，因为出错的地方更少。 在业务环境中，这是一个非常理想的功能，并且在我看来，这是 Domino 的一项杀手级功能。 这是我们今天仍然使用 Domino 的原因之一。

开发工具

Domino 应用程序是使用称为 Domino Designer 的 IDE（集成开发环境）开发的。 它位于跨越低代码和专业代码开发的空间中。 从历史上看，Domino 应用程序很简单，并且是使用旨在面向业务用户的工具集开发的，我们今天称之为公民开发者。 例如，表单是在一个与富文本文档编辑器非常相似的编辑器中构建的。 如果您对 Microsoft Word 感到满意，那么您就成功了一大半。 它不是现代低代码平台所称赞的拖放式编辑器，但它同样直观。 您也不需要单独设计数据库，当您向表单添加字段时，Domino 会为您完成其余工作。 Domino 通过其公式语言从无代码转移到低代码。 计算字段、视图列、视图选择、操作等都使用此公式语言。 有时将其称为“at-formula”，因为它的所有函数都以 @ 符号开头。 它在复杂性上类似于您在电子表格中找到的公式，因此仍然旨在供公民开发者使用。 更高版本的 Domino 引入了 LotusScript。 这是一种通用编程语言，其语法类似于 Visual Basic。 它支持过程、函数和面向对象，并带有一个完整的类库，用于操作 Domino 应用程序。 它更适合于更复杂的任务或需要重用的情况。 这也是我们开始失去公民开发者并需要专业人员的地方。 Domino 应用程序中用于自动化的多用途英雄是代理。 这些是独立的、可以从操作、事件、Web 或按计划触发的代码单元。 正是代理将文档存储库转变为工作流应用程序及其他应用程序。 可以预见的是，可以使用公式语言或 LotusScript 编写它们。 也可以使用 Java 编写它们，并且您可以导入您需要的任何自定义或第三方库。 这确实提高了您可以在 Domino 应用程序中编写代码的标准。 如前所述，当通过 Web 浏览器访问应用程序时，您可以（并且应该）覆盖 Domino 生成的默认 HTML。 这将 HTML、CSS 和 JavaScript 添加到正在使用的技术组合中。 开发现代 Domino Web 应用程序所需的技能集与其他全栈开发人员所需的技能集并没有太大的不同。 Web 技术用于前端，LotusScript 和/或 Java 用于后端，Domino 用于数据库。 可以认为 Domino 是最初的低代码开发平台，我听到有些人实际上对此进行了争论。 虽然对于某些简单类型的应用程序来说是正确的，但对于大多数应用程序来说并非如此。 当我开始 Domino 开发时，它被描述为快速应用程序开发或 RAD。 我更喜欢这个术语，因为它更准确地描述了这种情况。 Domino 使一些常见的开发任务变得像点击一样简单，这反过来使开发速度出奇地快。 但是，它也提供了在需要时使用完整专业代码的工具。 Domino Designer 与普通的 Notes 客户端一起安装，它共享所有相同的身份验证和连接配置文件，因此几乎不需要额外的设置。 您无需担心安装插件或连接到项目存储库，它就可以正常工作。 但是，并非一切都是玫瑰色的，IDE 正在老化，并且迫切需要一些升级。 它主要基于 Eclipse，其中一些编辑器是从较旧的 Eclipse 之前的版本中提取的。 它有一些有趣的错误，尤其是在某些侧面板的呈现方式上。 但最令我恼火的是 JavaScript 编辑器不支持 ES6，并且拒绝保存有效的 JavaScript，因为它无法通过其过时的验证。 在向 Domino 介绍新开发人员，尤其是毕业生时，Domino Designer 的状态会引起很多尴尬。 与现代文本编辑器和 IDE 相比，它的表现不佳。 缺少暗模式几乎是某些毕业生的一个阻碍。 他们需要几个月的时间才能看穿这些怪癖和问题，并认识到 Domino 的价值。 Domino 的 RAD 开发方法是一个真正的优势，也是产品的重要组成部分。 然而，RAD 开发并非 Domino 独有，过时的 IDE 使其黯然失色。 因此，在我看来，它不是杀手级功能之一，但绝对值得一提。

自包含

我特别喜欢的一个功能是 Domino 应用程序如何自包含在单个 NSF 文件中。 Domino 数据库中的文档可以存储任何内容，通常这是字段的集合，但它也可以是二进制数据。 因此，应用程序可以存储其自己的设计，包括所有表单、代码、图像、库等。 永远不会出现应用程序的逻辑在哪里的问题，它与数据位于同一数据库中。 这就是为什么术语“数据库”和“应用程序”在 Domino 方面经常互换使用的原因。 它们具有相同的范围，并且在很大程度上是同一件事。 从管理的角度来看，它具有几个优点。 例如，要备份应用程序，您需要复制一个 NSF 文件。 这将为您提供运行该应用程序所需的所有数据、逻辑和元数据。 如果您需要将应用程序移动到不同的环境，只需复制该单个文件即可。 通常，您唯一需要考虑的额外事项是用户和组，默认情况下，它们也存储在 Domino 数据库中，只是一个由所有应用程序使用的集中式数据库。 这也使应用程序部署变得轻而易举。 任何 NSF 都可以标记为模板，Domino 提供了一个系统来同步模板和其他数据库之间的设计元素。 升级应用程序是一个简单的过程，即创建模板并触发设计刷新。 回滚需要恢复先前的模板并触发设计刷新。 所有精力都真正投入到模板管理中，这只需要一点纪律即可。 部署应用程序时，无需执行额外的步骤来将应用程序链接到数据库，按设计，它们已经链接在一起。 事实上，数据库、Web 服务器、服务器端引擎、计划任务、电子邮件、用户身份验证，运行应用程序所需的一切都由 Domino 提供。 显然，其中一些需要在首次设置环境时进行配置，但在应用程序部署时，除了设计刷新之外，您几乎无需执行任何其他操作。 仅当您还必须在升级过程中操作数据时，部署才会变得繁琐。 由于 Domino 是一个面向文档的数据库，因此我的经验表明这是一个例外，而不是规范。 因此，Domino 的运营部分成本非常低，并且根据公司的设置，开发人员负责运营是非常实际的。 当 DevOps 开始流行时，我很高兴地发现我已经使用新范例多年了，我只是不知道它有一个名字。 考虑一个具有 Microsoft 技术的类似应用程序。 您将需要 SQL Server 用于数据库，IIS 用于 Web 服务器，AD 用于用户和组管理，Exchange 用于电子邮件，DevOps Server 用于包管理和部署（我认为），以及 Visual Studio 用于实际开发。 这些中的每一个都是他们自己的学科，具有他们自己的安装过程、单独的设置、单独的工具和培训课程。 开发人员需要了解不同的 API 以及这些应用程序如何连接在一起。 管理员需要维护多个产品，或者根据我的经验，我需要多个管理员，每个人都专注于不同的产品。 运营更加耗时，需要更新多个产品并维护它们之间的链接。 相比之下，Domino 作为单个产品安装和作为一个单元进行管理。 除了一些罕见的例外，所有配置都存储在可以使用普通 Notes 客户端或称为 Domino Administrator 的高级客户端编辑的 Domino 数据库中。 对于较大的环境来说，它可能会变得很复杂，但相比之下，它相对轻松。 例如，当您在 Domino 中配置安全性时，您已经一次性地保护了数据库、Web 服务器、电子邮件以及所有内容。 使用其他平台，您可能必须为每个产品重复该过程。 Domino 的一体化方法也使其更加可靠。 例如，您无需担心依赖项管理。 数据库永远不会升级到 Web 服务器不支持的版本。 您无需花费时间来诊断为什么产品 A 突然停止与产品 B 通信，即使没有人声称更改了任何内容。 最终，Domino 作为一个单一平台，节省了时间和精力，提高了安全性并提高了可靠性。 开发人员可以将更多时间用于开发，而将更少的时间用于在技术之间进行上下文切换。 管理需要最少的资源，并且无需花费时间将数据库链接到 Web 服务器和服务器端后端。 有什么公司不希望其员工专注于增值并避免非生产性时间？ 对我而言，Domino 作为一个完整的软件包是第二大杀手级功能。

替代方案

还有其他解决方案声称是 Domino 的现代替代方案。 Microsoft SharePoint 经常被引用为替代方案，虽然它适用于简单的文档存储库，但它不是一个应用程序开发平台。 对于本地 SharePoint，您过去可以使用诸如 InfoPath 或 SharePoint 设计器之类的工具对其进行自定义，但是这两种工具都已停产。 您还可以使用诸如 Nintex 之类的第三方工具对其进行自定义。 但是，放弃 SharePoint 并开发一个传统的 .NET 应用程序可能会更容易。 对于 SharePoint Online，您会很快意识到您应该使用的是 PowerApps。 可能还有 Microsoft Dataverse。 然后，这开始看起来可疑地像 Microsoft Dynamics 365，并且您开始想知道是否应该改用它。 它可能都具有 Microsoft 品牌并通过 Microsoft 365 提供，但您又回到了需要使用多个产品的问题。 此外，还不完全清楚何时使用哪些产品，以及您是否甚至获得了使用它们的许可。 对于应用程序开发来说，一个更好的选择似乎是各种无代码/低代码平台。 Nintex 似乎正在慢慢脱离 SharePoint 并将自己作为独立的无代码/低代码平台进行营销。 K2 曾经在这个市场上，直到 Nintex 收购了他们。 Outsystems 和 Mendix 也被作为无代码/低代码应用程序开发平台进行营销。 HCL 甚至有 Volt MX。 我认为无代码/低代码是一个具有误导性的营销术语，因为它并非完全正确。 对于真正没有代码或低代码且旨在供公民开发者使用的工具，您会很快达到该工具可以完成的上限。 您最终会尝试创造性的、通常是耗时的解决方法来构建所需的逻辑。 此时，该工具更多的是阻碍而不是帮助，并且可以使用几行代码更清晰、更快速地描述该逻辑。 似乎任何足够成熟的无代码/低代码工具都已经得出了类似的结论，并且提供了一种在点击界面达到其限制时输入代码的方法。 这与我先前描述的 Domino Designer 并没有什么不同，在 Domino Designer 中，最初该工具可能是为业务用户设计的，但随着时间的推移，它已扩展为支持专业开发人员。 Nintex、K2、Medix、Outsystems 和 Volt MX 都位于该频谱上的某个位置，因此，至少从开发的角度来看，它们是 Domino 的潜在替代方案。 查看这些平台的另一种方式是“低管理”。 它们擅长的是获取运行应用程序所需的所有各种组件，将它们打包在一起并通过 SaaS（软件即服务）作为单个已安装程序或在线提供。 我在前一节中讨论的所有各种配置、依赖项和安全问题都由该平台吸收。 剩下的管理工作都通过一个漂亮的门户完成，并且开发是通过一个 IDE 完成的。 最大的问题是这些系统可能会变得很昂贵，尤其是 SaaS 系统。 我无法给出确切的数字，报价取决于许多因素，但它们至少比我们为 Domino 支付的费用高出一个数量级。 在 Microsoft 的情况下，这是除了我们已经拥有的 Office、SharePoint、Teams 等的许可证之外的。 对于大多数其他产品，我们还需要许可一个供系统使用的数据库，因为该数据库未包含在内。 似乎 Domino 对我们来说更便宜的原因是它的许可方式。 我们购买了一个实用程序服务器许可证，这基本上是一个每个服务器的许可证，它会考虑服务器的速度和处理器数量。 其他解决方案基于用户数量和/或应用程序数量。 如果您有很多应用程序和/或很多用户，那么这会很快加起来。 HCL 还为 Domino 提供每个用户的许可。 多年来，他们一直鼓励客户切换模型。 每次我续订我们的许可证时，我们的 HCL 业务合作伙伴都会说我们应该切换，并在审查我们的用户数量后仍然以每个服务器的报价返回。 我自己的使用公开可用数据的估计值使成本与其他平台保持一致，大约贵十到一百倍。 如果我们使用 Domino 的所有功能，并且我们的用户正在使用 Notes 客户端，我们将不得不切换到每个用户的许可证。 开发所有应用程序以通过 Web 浏览器访问并且仅使用应用程序开发和托管功能意味着我们可以只许可服务器。 当将 Domino 与其他解决方案之一进行比较时，企业很难证明成本的增加是合理的。 最终，坚持使用 Domino 是明智的选择。 在我看来，这使 Domino 的每个服务器许可模型成为第三大杀手级功能。

HCL 在做什么？

HCL 宣布他们将停止每个服务器的许可。 该公告将此描述为“许可证简化”，以及每个服务器的许可如何“基于处理器价值单元许可，这是一种在现代云/ Kubernetes 世界中不再相关的旧许可证指标”。 您可以在此处阅读完整的博客文章。 我确信对于某些客户来说，这是一个非事件。 我想这取决于您如何使用 Domino。 我们被告知切换应该是成本中性的，但我从未收到书面形式的声明，并且我仍在等待使用新模型的报价。 我知道正常的每个用户成本是多少，以及我们目前支付的费用是多少，并且数学计算不正确。 当我们的许可证即将续订时，这将是一个难以接受的事实，并且我将不得不再次向管理层证明 Domino 是合理的。 HCL 在 2019 年购买了 Domino，此后一直在继续投资该平台。 大约每年发布一个版本。 除了错误修复和我所认为的需要解决的大量技术债务之外，HCL 还发布了一些重要项目。 例如，HCL 发布了适用于 Apple、Android 和 Web 的 Nomad 客户端。 这使您可以在移动设备和 Web 浏览器上运行 Domino 应用程序，而无需任何额外的开发。 应用程序的外观和工作方式与在普通 Notes 客户端中相同。 对于尚未重新开发其应用程序以在 Web 上运行的组织来说，这是一个绝佳的选择，无论是使用传统的 Domino 开发还是 XPages。 对我们来说，它几乎没有用处，因为我们已经完成了艰苦的工作。 HCL 还发布了 Domino Leap（最初是 Domino Volt）。 这是一个基于 Web 的低代码 IDE，它使用 Domino 作为后端。 一段时间以来，我们一直在与想要开发自己的应用程序的业务用户一起试用它。 在一个熟悉的故事中，用户很快尝试做一些该工具无法支持的事情，并且大多放弃了。 除了一位用户发现您可以添加自己的 JavaScript 并且疯狂地开发自己的东西。 值得 HCL 称赞的是，Leap 的发布节奏大约每 6 个月一次，并且该产品从最初发布时有了很大的改进。 但是，Leap 被许可作为 Domino 的附加组件，因此，尽管它可能很有用，但我无法使用它来证明基本产品成本的增加是合理的，因为无论如何我都需要额外付费才能使用它。 Notes 客户端进行了一些改进，通常我对这些改进不感兴趣，除非它们替换了微小的属性对话框。 有点儿吧。 他们实际上添加了第二个“高级”属性框，但它不能替换原始属性框，因为它仅涵盖了原始属性框的部分功能。 所以现在我有两个属性对话框。 从开发人员的角度来看，我认为最大的更新是 LotusScript 中的 JSON 解析器和新的 REST API。 于 2023 年 12 月发布的 Domino 14 包括一个新的 JavaScript 编辑器，不幸的是，在编辑 JavaScript 库时，它仍然会在保存时触发一个旧的验证器，该验证器会拒绝 ES6 语法并拒绝保存。 他们还发布了一个以与 Nomad 客户端相同的方式在 Web 浏览器中运行的 Domino Designer 版本。 这是面向那些想要适用于 Apple 或 Linux 的 Domino Designer 客户端的人员进行营销的。 我承认我还没有试用过此客户端，但我想看看它是否修复了 JavaScript 验证问题，以及属性面板仍然存在于 14 版本 Windows 客户端中的呈现错误。 当我努力回忆我们在过去四年中收到了哪些改进对我们使用 Domino 产生了显着影响时，我意识到仅凭这一点不足以证明成本的显着增加是合理的。

荣誉奖

我还没有涵盖我喜欢 Domino 的所有内容，这篇文章已经足够长了，但在我总结之前，这里有一些荣誉奖。 Domino 数据库支持复制。 这对我来说比现在更重要。 在 00 年代，当网络速度慢、成本高且远非始终在线时，我们在每个办公室都有一台 Domino 服务器，并使用复制来保持一切同步。 今天，我将所有应用程序托管在一台服务器上，因此我不需要复制，但如果我的情况发生变化，它就在那里。 还支持集群，并且随着应用程序使用量的增长，我已经开始考虑将其作为添加一些负载平衡和弹性的选项。 Domino 非常向后兼容。 20 多年前为 Domino 4.5 编写的应用程序今天仍然可以工作。 从理论上讲，您可以返回更早的版本，我只是从未尝试过。 根据我的经验，我们在升级 Domino 时经常遇到的唯一问题是默认的 fav 图标被重置。 否则，我们会小心测试我们已脱离 Domino 以访问其他系统或工具的任何地方，但核心 Domino 功能会继续工作。 这使得保持最新几乎微不足道，并使我们的安全团队免受我的困扰。

等等，电子邮件呢？

您可能已经注意到我并没有真正讨论电子邮件。 这是因为我将 Domino 视为一个应用程序开发平台，其中它可以做的一件事是电子邮件，并且开箱即用的应用程序之一是电子邮件客户端。 这不是绝大多数用户看待它的方式，对他们来说，Notes 是一个糟糕的电子邮件程序，也可以做其他事情。 我理解他们的观点，在一段时间内，Notes 作为“仅仅”一种电子邮件解决方案进行营销和销售，因此许多用户仅将其用于电子邮件。 虽然 Notes 中的电子邮件功能很全面，但它有所不同。 电子邮件（或曾经是）被称为备忘录，揭示了 Notes 的年代并向 Notes 正在取代的基于纸张的内部备忘录致敬。 这在 1989 年可能更有意义，但对于 21 世纪的新用户来说却令人困惑。 其他术语也同样不直观，而不是发送和接收邮件，您复制了您的邮件文件。 虽然从技术上讲是正确的，并且暗示了 Notes 程序的更广泛范围，但对于某些用途来说，它只是令人困惑。 将这些可用性问题添加到客户端的总体用户体验不佳，很容易理解为什么任何不得不仅将 Notes 用于电子邮件的人都因这次体验而感到恐惧。 对于任何人仍然仅将 Notes 用于电子邮件和日历，尽管最近进行了改进，但我认为您使用了错误的产品。

最后的想法

我不确定我们使用 Domino 的方式是否罕见或相当普遍。 根据 HCL 似乎关注的功能，有很多公司仍在