携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第23天，点击查看活动详情 >>
前言
领域驱动设计(DDD)在后台是很火的一个架构设计模式，这里引用一下张逸老师在《领域驱动战略设计实践》中的话
面对客户的业务需求，由领域专家与开发团队展开充分的交流，经过需求分析与知识提炼，以获得清晰的问题域。通过对问题域进行分析和建模，识别限界上下文，利用它划分相对独立的领域，再通过上下文映射建立它们之间的关系，辅以分层架构与六边形架构划分系统的逻辑边界与物理边界，界定领域与技术之间的界限。之后，进入战术设计阶段，深入到限界上下文内对领域进行建模，并以领域模型指导程序设计与编码实现。若在实现过程中，发现领域模型存在重复、错位或缺失时，再进而对已有模型进行重构，甚至重新划分限界上下文
每个字都认识，合起来就看不懂了对吧？我也是，所以下面我尝试以我的理解，来描述一下，领域驱动设计的思想是怎么样的
领域驱动设计之我的看法
前端比较熟悉的设计模式，一个是MVC，一个是MVVM，都是基于模型-视图-控制器，或者是模型-视图-视图模型这样的实现来走的，领域驱动设计的他主要就是基于现有需求来设计领域模型，通过领域模型提供的能力来驱动业务，这里需要高度的抽象和合理的边界划分也就是领域设计，基于高效拆分的领域模型可以通过软代码来实现不同级别的复用和组合
领域驱动设计之我的思路
以我正在写的面向某个小众领域的专业低代码平台为例，这里的专业不是指技术上，而是业务上，更多是为了实现特定行业内需求而设计的低代码平台，我的低代码设计之初想要实现的效果是，通过内置的界面布局组件和内置的动态帮助函数，梳理现有的业务模型和界面，实现特定界面的逻辑抽取和页面复用， 基于这样的设计思路，我在设计之初分为了三大领域：系统内置模块，编辑器，解析引擎，系统内置模块主要是为了实现低代码平台底层逻辑而必须的一些系统界面，如数据源管理，表资源管理，枚举管理(当然枚举也可以通过编辑器的方式构建，因为比较常用，我放在了内置模块内) 编辑器包含对于模块功能的具体管理，比如表资源关联，界面模版，接口执行引擎配置等，解析引擎很好理解，就是基于编辑器所配置的相关界面模版和执行引擎，通过事件驱动的方式执行解析
领域驱动设计之我的具体实现
- 路由设计：路由上我采用静态参数路由+权限拦截器的方式去实现，这样的好处是不会出现动态加载路由后因文件加载延迟的白屏情况，而且基于权限拦截器可以自定义各类拦截
...
{
path: 'function/:moduleCode',
name: 'functionCreate',
meta: {
isParamsRoute: true,
title: '功能配置'
},
component: () => import('@/views/sys/function/create')
},
{
path: 'analysis/:moduleCode/:moduleType',
name: 'analysis',
meta: {
isParamsRoute: true,
title: '功能解析'
},
component: () => import('@/views/sys/analysis/view')
}
...
上面代码就是基于参数路由的动态匹配，通过meta元信息标识和$route的参数路由来正确读取对应配置
- 接口设计： 接口采用统一的invoke接口，并基于requestBody传入的参数进行动态调用，为接口多态提供可能
export async function invoke (params) {
return request(BASE_URL + '/etms/invoke', METHOD.POST, params)
}
- 编辑器： 根据我要解决的具体业务，将编辑器内的界面设计拆分为列表模版和表单模版，通过托拉拽的方式进行实现，因为本身业务是ToB业务，所以基于业务的具体执行情况又设计了内置的几类模版去覆盖现有的业务需求，页面内所有元素包括按钮均为模版配置，低代码平台本身仅提供抽象出的基于页面和数据的操作方法帮助对象，一切业务实现都是软代码，基于前端事件驱动
- 界面与后台交互均设计为按钮，在按钮上绑定接口编码并根据接口编码配置对应的执行类或者执行配置，同样提供内置执行类与执行配置。
