领域元组件是一个包含特定领域组件（业务场景）的集合。其内部包含了一系列的组件，依赖于输入的领域元数据或者领域特定语言，构建出适用于特定领域的组件。

这个概念的定义是源自于在领域驱动设计的思想来构建的。简单来说，在特定的领域里，它所需要的业务组件是有限的，有限的业务组件构成了系统的页面、组件与模板。如果我们进行适当的组件化与封装，那么通过传入相应的业务数据，就能渲染出所需要的页面、包含业务功能的组件等。

条件渲染

过去，设计低代码系统时，我曾经有类似的想法，只是觉得它并不适合于低代码的场景。或者说，它并不适合于低代码场景的生产运行时，但是可以有限的用于低代码的开发时。除了在编译时，需要去除这些对于条件判断之外，我们还构建了一部分的交互逻辑。随后，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;
}

原理上就是简单，重点还在于其适用的场景来看。

适用场景

从再有的定义来看，我觉得它适用的场景有：

1. 限界低代码（开发时）。
2. 渲染引擎。如 markdown 编辑器
3. 遗留系统迁移。
4. 展示为主的场景。如 Dashboard 等可自定义展示的页面。

对于低代码、渲染引擎和 Dashboard 来说，我们都很容易理解。唯一令人会疑惑的是，如何在系统迁移中，使用这个方式。

遗留系统迁移

对于改造遗留系统来说，将现有的应用拆为了多个微应用的改造成本是巨大的。所以呢，换个思路，我们只需要使用领域元组件 + Web Components 的方式，就能在不拆分现有应用的情况下，提供现有应用的能力。简单来说，过程就是：

1. 抽象待复用组件，提炼公共的数据。
2. 创建一个 MacroRenderComponent，构建条件渲染模式。
3. 封装创建 Web Components 组件，提供对外的能力

这样一来，就可以在不需要大幅改动的情况下，迁移再有的遗留系统。

其它：vs 微前端

微前端架构确实是一种非常不错的方案，但是它带来的巨大的改造成本，让我进一步地思考了更多的方式来迁移前端应用。