前言

公司在开发复杂业务中（电商系统黄金流程）往往面临着复杂页面的场景，每个应用页面显示方式多种多样、千人千面。很难做到一套UI多人通用和兼容。 那么此时会面临多诸多技术挑战，页面不断变化开发者每次都要将每个楼层的数据按照产品要求的样式返回填充进行返回，一次两次调整开发者也无需承担过大的工作量 但是随着业务的不断增多，样式变化不断增多，而开发者的人力还是之前的人力，那么就会面临大量的重复工作和没有意义的工作量充斥着开发者，伴随的为开发者带来了 巨大的困扰，那么此时我们应该怎么办呢？ 任由此种情况发生吗？ 答案当然不是！

如何打破僵局？ Cube为此而诞生！为降低开发成本、提高系统配置化、提升楼层共建效率，同时提供灵活的模板数据通过"魔方"组合的方式进行动态组装数据 与DDD的领域服务节藕组合相呼应。并且兼容 前端LowCode 可视化搭建平台（组件、楼层）。此时开发者再也不用担心楼层数据经常变化啦。同时如果需求方需求紧急 的情况下，也可以使用共建楼层模式和独立楼层模式快速接入开发和上线（共建房具备研发能力）。你会发现打造一个低耦合，灵活的系统会变得易如反掌！

为什么叫Cube

Cube（魔方）又叫鲁比克方块，最早是由匈牙利布达佩斯建筑学院厄尔诺·鲁比克教授于1974年发明的机械益智玩具。魔方拥有竞速、盲拧、单拧等多种玩法，风靡程度经久未衰，每年都会举办大小赛事，是最受欢迎的智力游戏之一。 通常意义下的魔方，是指狭义的三阶魔方。三阶魔方形状通常是正方体，由有弹性的硬塑料制成。常规竞速玩法是将魔方打乱，然后在最短的时间内复原。广义的魔方，指各类可以通过转动打乱和复原的几何体。 寓意让开发者设计数据返回时能像组装魔方一样轻松欢快，同时数据又像魔方形态一样多种多样，变化万千。

Cube框架的优势

如果你要对复杂业务逻辑进行新写或者重构，用Cube最合适不过。他是一个可以让你完成复杂的业务场景下数据灵活编排组装的利器。让每个原子性单元成为一个领域能力。 每个领域能力都是一个最小单元。可以理解成最小数据单元（抽象化数据库的 表中的一个"列字段"）。通过领域能力组装成N个领域服务（抽象化数据库的表）

使用Cube，可以将你返回给前端的数据灵活拆分成一个一个小领域能力。同时在每一个领域能力所依赖的数据源（RPC、HTTP、数据库）还具有异步任务编排的能力。

而这一切只需要你定义好领域能力，设计好RPC任务编排依赖顺序（想使用任务异步编排能力时），通过Cube DashBoard 你可以轻松完成所有JSON 数据的灵活配置。

你有想过，要在代码中实现下面这种复杂逻辑流程该如何实现吗？

领域能力

领域服务

同时所有领域服务都是动态创建出来的， 区别与DDD的通过coding设计的 固定的领域服务（如后续改变领域服务则需要重新开发代码上线）

组件

提示

此处组件完全匹配 前端LowCode可视化低代码平台的组件概念，此处的组件即为前端组件提供数据服务，前端每开发出来一个组件即可来Cube平台创建 它所需要的数据源信息即可

楼层

提示

通过创建多类型楼层（核心楼层、共建楼层、独立楼层）选择合适该楼层的动态组件，即可完成楼层数据的加载和获取。

模板

提示

拥有了多个楼层作为基础数据源，模板自然轻松可以通过配置化创建出来，同时将模板与应用进行关联即可完成应用获取模版数据。

配置信息

提示

以上都配置好之后，即可发布模板，Cube 魔方平台会自动创建所属应用的配置信息。同时提供JSON可视化和下方的数据可视化的能力

数据可视化

而以上这一切，利用Cube，轻而易举，你立马唾手可得！

Cube 设计原则

一、Cube是基于插件（微内核）模式进行设计的，何为微内核模式？

想必使用过Dubbo的同学都有了解。Dubbo就是使用了SPI的微内核技术。 使得架构具有高度的扩展能力，方面使用者自行扩展，这也是为什么Dubbo选择使用微内核架构。

"微内核" 架构也被称为插件式架构，它是一种面向功能进行拆分的架构模式，除了我们聊过的的Dubbo以外，我们日常使用的IDEA、Eclipse这类IDE软件，操作系统，银行系统等都是采用了这种架构模式。

通过以上的介绍想必大家都对 "微内核" 有一定的了解， 不错！正巧Cube 也是基于这种设计思想进行开发和设计。因为有的开发者并不想使用 共建楼层和独立楼层， 仅仅想使用核心楼层 所带来的业务数据节藕的能力。 那么此时通过 SPI的动态扩展，按需加载对应楼层的 SDK即可完成所需的楼层扩展能力。

二、责任链设计思想

众所周知，责任链思想在很多架构中都有涉及（Sentinel、Tomcat、Spring），随处可见的责任链设计思想为什么这么好？

• 优点

① 解耦 : 请求的 发送者 和 接收者 解耦 ; 接收者 是 请求的处理者 ;

② 动态组合 : 责任链 可以 动态组合 , 使用配置 设置责任链的 顺序及 是否出现 ; 可以随时对责任链排序 , 随时增加拆除责任链中的某个请求对象 ;

• 缺点

① 性能 : 如果 责任链 太长 , 或责任链中请求的 处理时间过长 , 可能会 影响性能 ;

② 个数 : 责任链 可能过多 ;

正巧Cube中也广泛使用了责任链模式。在建设领域能力、领域服务、组件、楼层、模板中涉及到一系列的数据加载组装的执行过程。所以责任链的设计思想 正是该框架的架构所需！

Cube适用于哪些场景

• 后端业务繁杂，频繁变更业务数据时
• ISV建设、楼层化建设时（共建楼层、独立楼层）
• 受阻于DDD开发，领域服务边界定位不精准，设计难度大时
• 想拥有异步任务编排、业务数据灵活组装时
• 大前端开发架构定位不明确时，通过可插拔方式选择核心楼层建设