可逆计算

Paxos算法是分布式领域中一个非常基本的算法，一向以晦涩烧脑著称。但是它之所以让人感到摸不着头脑，主要是因为我们不容易直观地理解它为什么要这样设计。尽管我们可以通过具体例子来验证其正确性，甚至可以用

最近面试中发现很多人对于函数式编程的理解就是Lambda表达式和flatMap/map/join这种集合处理函数，对于函数式编程为什么有用，在什么场景下有用只有很模糊的感觉。在本文中，我就简单介绍一下

最近有同学介绍我看一篇金蝶云苍穹的文章，都1202年了，听说还有人不知道扩展与继承的区别，这其中介绍了一个有别于传统继承概念的所谓 扩展(Extension)概念。这个概念也不是云苍穹原创的，在odo

Nop平台基于所谓的可逆计算理论从零开始编写，它的整体实现可以看作是如下软件构造公式在不同抽象层面的反复应用 为了将这个抽象公式落实为具体的技术实现，Nop平台内置了一系列的通用机制，用于实现Gene

Nop平台可以看作是一个语言工作台（Language Workbench），它为DSL(领域特定语言，Domain Specific Language)的设计和研发提供了完整的理论支撑和底层工具集。使

可逆计算理论提出了一个通用的软件构造公式 Nop平台的整个实现可以看作是对这个公式的一种具体落地实践。这其中，最关键也是最容易引起误解的部分是可逆计算理论中的差量概念，也就是上面公式中的Delta。

1. 代理对象=被代理对象时，代表双向可逆转换吗？ 不是。代理对象或者说任何一种基于接口或者多态实现的解决方案，都可以看作是一种数学上的同态（homomorphic）映射，在范畴论中也就是所谓的函子(

NopTaskFlow是基于可逆计算原理从零开始编写的下一代逻辑编排引擎。因为逻辑编排引擎并不是一个新鲜事物，国内外都有很多开源实现，所以很多人可能对于NopTaskFlow的独特性有所怀疑。为什么它

很多年以前知乎上就有人对GraphQL的作用进行过讨论，这么多年过去，在实际的商业开发中还是很少见到大规模使用GraphQL的情况。这是否意味着GraphQL的设计存在问题，如果存在，到底是设计不足还

Nop平台内置了基于可逆计算原理从零开始设计的下一代GraphQL引擎NopGraphQL和下一代ORM引擎NopORM，它们结合在一起可以很容易的实现类似APIJSON的功能，并且提供更好的可扩展性

Nop平台采用代码生成的方式实现了一个最简单的AOP机制，具有最优的性能且完全满足我们一般应用的需求，全部代码仅有不到2000行。

Nop平台没有使用graphql-java等常用的GraphQL开源库，而是选择从零开始实现NopGraphQL引擎。NopGraphQL引擎创造了很多崭新的实现方案，拓宽了GraphQL的应用范围，

在开发一个产品化的业务系统时，经常会出现需要扩展基础产品中的已有服务的情况。比如说，扩展系统内置的Login服务，为LoginRequest增加更多的请求参数，或者扩展返回的LoginResult对象

Nop平台提供了类似MyBatis的动态SQL管理能力，但是功能特性远比MyBatis丰富、强大。同时它的实现反而更加简单，在NopORM的基础上实现SqlLibManager只需要300多行的代码。

B站视频：https://www.bilibili.com/video/BV1c1421i72k/ Nop平台中查询服务的执行过程包含三个主要部分： 定位到服务对象 调用服务对象上的服务函数 对返回结

Nop平台支持自定义的模型驱动代码生成机制，这个机制可以在Nop平台之外独立使用。这里以消息对象模型为例，演示如何通过配置实现对消息对象模型的解析和代码生成。 B站讲解视频: 地表最强的模型驱动代码生

很多低代码平台的核心其实就是一个CRUD模型，一般通过内置的扩展点（比如插入前、插入后等）来提供一定的可定制性。Nop平台中CRUD模型没有任何的特殊性，它内置的CrudBizModel仅仅是一个普通

Solon是一个基于Java的国产轻量级微服务框架，详细介绍参见官网https://solon.noear.org/ 。Solon的启动速度很快，占用内存很小，可以作为SpringBoot的一个替代品

DQL(Dimentinal Query Language)语言是润乾公司提出的一种面向OLAP的多维数据查询语言，可以将复杂的主子表很简单的整合为一个大宽表来查询。具体介绍可以参考乾学院的文章 告别

视频介绍 在微服务架构下，服务是某种粗粒度的可以被复用的单元。在跨业务领域的协同中，我们可以引入服务编排引擎，来对微服务调用进行灵活组合。 但是当我们聚焦到一个服务内部的逻辑结构的时候，我们需要更加高