正确看待它
低代码开发速度快
低代码，特别是低代码应用程序开发平台，旨在弥合业务和 IT 之间的差距，同时提高整个软件开发生命周期的敏捷性、生产力和整体开发体验。应用程序和服务不是编码的，而是在统一的可视化建模环境中建模的，该环境抽象化了传统软件开发中经常遇到的许多复杂性。

低代码还旨在通过其可视化建模方法让更多的人参与设计和开发过程，当我们进入数字时代时，它对精通技术的“公民开发人员”也非常有吸引力。低代码的目的通常倾向于较小的部门和以产品为中心的解决方案，以及在核心系统之上提供适合目的 UI/UX 的差异化和创新解决方案。

最新的 DZone 参考卡

NoSQL 迁移要点

微服务很简单
微服务是简单、轻量级且松散耦合的服务，使各个团队可以更轻松地处理其域内的可管理部分。这种领域驱动和自主的软件开发方法也与 DevOps 和规模化敏捷转型等流程和组织趋势很好地契合，这些趋势使组织走向更加自主和以产品为中心的团队。

这些微服务团队与自治团队有相似之处，自治团队可以对自己的以部门和产品为中心的低代码解决方案进行建模，并且这两者可以潜在地融合。

微服务架构很复杂
尽管各个微服务设计得很简单，但围绕所有这些较小的移动部件所需的整体架构和治理的复杂性却在增加。例如，微服务应该能够单独部署、监控、编排和扩展，而不会相互影响。

必须仔细设计许多方面，以使该架构实现其真正的承诺，即更加高效、灵活、可扩展和有弹性。与从组织角度来看低代码解决方案与微服务融合相反，复杂的微服务架构本身及其引入的设计问题通常无法仅靠低代码团队来解决，并且需要额外的专业知识和工具。

为成功做好准备
把事情简单化
当主要与公民开发人员合作时，最好只关注微服务架构的外部边缘和为最终用户提供 UI/UX 的模型应用程序。这更适合该受众，并且避免暴露于更复杂的底层微服务架构问题。通过记录完善的 API 公开微服务的集成点，使普通开发人员也可以更轻松地识别它们并将其集成到他们的应用程序中。

对低代码微服务进行建模的低障碍方法是从整体设计开始，只有在以后需要时才逐渐将其分解为微服务。当目的是尝试创新或首先在现场快速验证最小可行产品而不从一开始就需要微服务架构时，这种方法通常很有效。

尽管用低代码建模微服务本身很简单，但这还不能使其成为一种架构。当微服务只是单个且定义良好的解决方案的一部分时，这很好，但是当它们还打算被真正的微服务架构中的许多已知和未知的消费者重用时，请注意复杂性会增加。

关注用户交互
微服务架构通常专注于后端，而前端仍然作为架构外部的整体实现。低代码应用程序开发平台；然而，非常重视直接与业务和最终用户合作，以​​创建适合目的的 UI/UX。除了对微服务进行建模之外，低代码还可以使团队更轻松地对其前端进行建模，同时减少对专业前端技能和单独团队的依赖。

了解域
设计思维方法（例如通过客户旅程映射）是识别与最终用户的接触点的一种方法，这些接触点可以从需要 UI/UX 的微服务中受益，这使得它们非常适合使用低代码平台进行建模。

领域驱动设计原则还可以帮助定义微服务的范围以及它们如何作为独立服务以及在真正的微服务架构中高效交互。

微服务不仅要从技术角度履行单一职责，还要从业务角度履行职责，避免业务领域耦合在一起。当组织已经与规模化的敏捷和独立的产品团队合作时，它也会有所帮助，因为这也有助于为微服务定义某些逻辑边界。

传达有意义的信息
当微服务共享不完整的信息时，它们之间的交互会增加，这会降低性能并减少松散耦合。以互联网提供商的客户移动到新地址为例；其他微服务是否应该知道地址更新或客户正在搬家？

当微服务需要知道地址更改的原因以及是否需要启用或禁用任何产品时，第一种方法可能会导致多次交互。相反，如果您直接告知客户正在搬家，那么所有相关信息都可以共享。

它涉及整个软件开发生命周期
低代码建模和微服务架构都旨在提高软件开发的敏捷性。真正的微服务有其独立的生命周期，其中许多微服务需要依赖 CI/CD 管道和容器编排平台等自动化来保持敏捷。 

因此，了解敏捷团队的成熟度及其成功应用 DevOps 实践的能力也很重要。低代码应用程序开发平台通常提供监控和开箱即用的 CI/CD 管道来解决部分技术问题，但组织和人员方面无法仅靠任何平台来解决。