领域元组件是一个包含特定领域组件(业务场景)的集合。其内部包含了一系列的组件,依赖于输入的领域元数据或者领域特定语言,构建出适用于特定领域的组件。
这个概念的定义是源自于在领域驱动设计的思想来构建的。简单来说,在特定的领域里,它所需要的业务组件是有限的,有限的业务组件构成了系统的页面、组件与模板。如果我们进行适当的组件化与封装,那么通过传入相应的业务数据,就能渲染出所需要的页面、包含业务功能的组件等。
过去,设计低代码系统时,我曾经有类似的想法,只是觉得它并不适合于低代码的场景。或者说,它并不适合于低代码场景的生产运行时,但是可以有限的用于低代码的开发时。除了在编译时,需要去除这些对于条件判断之外,我们还构建了一部分的交互逻辑。随后,2020 年开发 Ledge 时,用了这种思想构建了 Ledge 渲染引擎。只是,始终觉得这种方式的适用场景是有限的。在最近编写 Quake 的时候,发现这种模式依旧适用,并且可以跨到更大的范围里。
如 Quake Render 中 <quake-render>
的 render 函数:
render() {
return <div ref={(el) => this.el = el as HTMLElement}>
{this.data.map((item: any) =>
this.conditionRender(item),
)}
</div>;
}
随后,根据不同的数据来展示结果:
private conditionRender(item: any) {
let out: string;
switch (item.type) {
case 'heading':
out = this.renderHeading(item);
break;
case 'blockquote':
out = <blockquote innerHTML={item.text}/>;
break;
...
default:
out = <span/>;
}
return out;
}
原理上就是简单,重点还在于其适用的场景来看。
从再有的定义来看,我觉得它适用的场景有:
对于低代码、渲染引擎和 Dashboard 来说,我们都很容易理解。唯一令人会疑惑的是,如何在系统迁移中,使用这个方式。
对于改造遗留系统来说,将现有的应用拆为了多个微应用的改造成本是巨大的。所以呢,换个思路,我们只需要使用领域元组件 + Web Components 的方式,就能在不拆分现有应用的情况下,提供现有应用的能力。简单来说,过程就是:
这样一来,就可以在不需要大幅改动的情况下,迁移再有的遗留系统。
微前端架构确实是一种非常不错的方案,但是它带来的巨大的改造成本,让我进一步地思考了更多的方式来迁移前端应用。
围观我的Github Idea墙, 也许,你会遇到心仪的项目